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Abstrakt 


Att arbeta i projektform inom mjukvaruutvecklingsbranschen har varit ett påstående som fått 
stöd ända sen branschens ursprungsdagar. Inom dessa projekt har rollen teknisk projektledare 
befästs. Rollen har ingen standardiserad innebörd men utgår i denna studie från en ledare som 
har ett övergripande ansvar för organisationens nyutveckling. Företag har historiskt sett 
tilldelat rollen teknisk projektledare till den mest tekniskt kompetenta inom företaget. Även 
om denna trend har kommit att förändras är det ännu oklart vilken nivå av teknisk kompetens 
som krävs av en teknisk projektledare. Genom att kombinera teorier om projektledning, 
mjukvaruutveckling samt kompetens med en kvalitativ undersökning redogör vi för 
teoretikers och branschspecialisters åsikter. Studiens syfte är att identifiera betydelsen av 
teknisk kompetens hos tekniska projektledare. Det som har framkommit från denna studie är 
att teknisk kompetens inte är en betydande faktor för att kunna axla rollen som teknisk 
projektledare. Men den tekniska kompetensen underlättar avsevärt kommunikationen med 
utvecklarna vilket kan vara betydande i företagsspecifika fall. Dessutom visar studien på att 
tillämpningen av de agila utvecklingsmetodikerna ställer nya krav på den tekniska 
projektledaren. 
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1 Inledning 


1.1 Bakgrund 


Projektarbeten har historiskt sett haft en varierande utvecklingstrend. Arbetssättet 
introducerades under 1900-talet och beroende på vilken bransch det används i har 
benämningen projektarbete haft olika betydelse. I byggbranschen användes uttrycket som ett 
första utkast på exempelvis en ny byggnadsritning. (Macheridis, 2005) I dagens samhälle har 
uttrycket projekt adopterats av flera branscher. Det är exempelvis inte ovanligt att tv- 
spelsbranschen använder begreppet projekt för ett spel som är under utveckling. (Jenselius, 
2010) 


Enligt Macheridis (2005) var projektarbeten under 1900-talet inriktade mot tids- och 
resursplanering. Det var inom konstruktionsindustrin som den huvudsakliga utvecklingen för 
projektarbetet låg. Utvecklingen tog fart genom att Henry Gantt introducerande det så kallade 
Ganttschemat under åren 1910-1915. Andra aktörer var under mitten av 1900-talet även 
delaktiga i utvecklingen av planeringsscheman. Mellan 1940-1943 tog företaget Du Pont fram 
en teknik kallad Critical Path Method (CPM) vilken användes under Manhattanprojektet!. 
(Macheridis, 2005) 


Under årtiondena före1990-talet utvecklades sättet att bedriva projektarbeten mot att vara mer 
internationellt och med ökat fokus på kunskapsutveckling. Det var också under 1980-talet 
som mer fokus lades på projektledarfrågor. Under 1990-talet skedde något som fick 
utvecklingen att bedriva projektarbete att gå tillbaka till tidsplaneringsstadiet. Det var intåget 
av informationsteknologin (IT) som återigen lade fokus på tidsplaneringen. Nya sätt att styra 
tiden introducerades genom datoriserade program. Projektarbetets utformning fick helt 
plötsligt nya möjligheter tack vare IT: att integrera ekonomistyrning, resurstilldelning och 
andra sorters organisatoriska begrepp i projektplaneringen. Därefter har det varit populärt att 
driva de arbeten som haft att göra med IT och mjukvaruutveckling i projektform. (Macheridis, 
2005) 


Intresset för projektledning inom IT är stort och har växt kraftigt de senaste åren. Myrén 
(2010) beskriver hur projektledarens roll i IT-företag har förändrats. Från att vara endast en 
arbetsuppgift till att ha blivit en profession. Ett annat tydligt exempel på projektarbetens 
popularitet är de certifieringar som är tillgängliga genom Project Management Institute (PMI) 
eller International Professional Managers Association (IPMA). (Crawford, 2000) 


McNamara (2005) skriver att metoderna, som företag arbetade med i IT-projekt, ökade i antal 
under den senare hälften av 1990-talet och början av 2000-talet. Med introduktionen av flera 


! Projekt under andra världskriget som omfattade 130000 anställda och 22 miljarder dollar i kostnader (Blake & 
Östman, 2010). 


Teknisk kompetens hos tekniska projektledare i mjukvaruutvecklingsprojekt Alm & Carlioth 


agila mjukvaruutvecklingssmetoder som till exempel Scrum och Test-driven development 
(TDD) har nyanserade krav ställts på projektledare inom mjukvaruuveckling. Projektledaren 
måste ha traditionella ledaregenskaper samtidigt som han eller hon bör vara en så kallad 
”System thinker” för att kunna applicera agila metoder på ett bra sätt i en organisation. Att 
vara en ”System thinker” innebär att projektledaren ska se organisationer som en helhet eller 
som en levande organism snarare än något som kan delas upp i delar. (McNamara, 2005) 


Förutom dessa egenskaper ställs det ytterligare krav på projektledaren i ledningen av IT- 
projekt. Det mest vedertagna är att projektledaren ska ha goda tekniska kunskaper. Denna 
egenskap kan för många ses som ett grundläggande krav. Dock är det inte ovanligt att IT- 
projektledare saknar tekniska kompetenser och ändå leder mjukvaruutvecklingsprojekt. (Jalil 
& Shahid, 2008) 


Det finns två typer av projektledare inom IT-branschen, de tekniskt inriktade och de 
administrativt inriktade. Projektledarna kan delas in i roller där en teknisk projektledare 
ansvarar för utvecklingsarbetet medan en administrativ projektledare har det allmänna 
ansvaret för projektet och utvecklingen. (Görling, 2009) 


Den projektledningsteori som presenteras i denna studie är bara ett fragment av vad som finns 
tillgängligt. I arbetet med denna studie har vi uppmärksammat projektledningsteorier som är 
relevanta för en teknisk projektledare inom mjukvaruutvecklingsbranschen. Traditionellt sett 
har den tekniska projektledaren fokuserat på att uppdatera sina tekniska kunskaper 
(programmeringskunskaper) för att kunna bli en bättre ledare (Jalil & Shahid, 2008). Ett 
problem som blir synligt och som vi anser intressant är de nyanserade krav som ställts på de 
tekniska projektledarna i och med introduceringen av bland annat de agila 
utvecklingsmetodikerna. Oklarheterna i dessa funderingar har lett oss vidare mot de 
resonemang vi för i problemformuleringen 


1.2 Problemformulering 


De utvecklingsföretag vi mött under vår studietid uppmärksammar att företag inom 
mjukvaruutvecklingsbranschen ofta låter nyanställda utan erfarenhet inleda sin karriär på 
företaget med att programmera. Enligt dessa företag fungerar det som en inskolning i hur 
företaget arbetar både tekniskt samt organisatoriskt. Detta kan innebära att axlandet av en 
teknisk projektledarroll kräver vissa programmeringserfarenheter. 


När det gäller betydelsen av den tekniska projektledares tekniska kompetens för att leda 
utvecklingsprojekt har vi inte inte funnit någon svensk studie som tar upp frågan. Dock fann 
vi en studie som genomfördes i Pakistan år 2008 som involverade 28 projektledare inom IT- 
branschen. Den studien svarar på frågan om vilken egenskap som är minst önskvärd hos en 
projektledare. Det visade det sig att det var de tekniska kunskaperna. (Jalil & Shahid, 2008) 
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Det hade varit intressant att se vilket resultat denna sorts undersökning hade fått om den 
genomförts på tekniska projektledare i Sverige som är aktiva inom IT-branschen. Den 
ambition vi har är alltså att identifiera vilka tekniska kompetenser som krävs av en teknisk 
projektledare i mjukvaruutvecklingsbranschen. Med utgångspunkt från dessa fenomen har en 
forskningsfråga utformats som lyder: 


Hur betydelsefull är den tekniska kompetensen hos tekniska projektledare inom 
mjukvaruutvecklingsprojekt? 


1.3 Syfte 


Syftet med vår studie är att beskriva vikten av teknisk kompetens beträffande projektledaren 
inom mjukvaruutvecklingsprojekt. Detta för att få en ökad förståelse för den tekniska 
projektledares roll inom mjukvaruutvecklingprojekt. 


1.4 Avgränsning 


I denna studie kommer vi utvärdera tekniska projektledare som är verksamma inom den 
privata sektorn. En geografisk avgränsning inom Malmö- Lund regionen har gjorts för vi skall 
kunna genomföra personliga strukturerade intervjuer. 


Studien kommer inte behandla olika framgångsfaktorer för en teknisk projektledare. Studien 
kommer heller inte resultera i en jämförelse mellan tekniska och icke-tekniska projektledare. 
Studiens fokus ligger inte på en teknisk projektledares projektledaregenskaper, exempelvis 
kommunikationsförmåga. Denna studie kommer att koncentrera sig på den tekniska 
projektledarens tekniska kunskaper inom mjukvaruutvecklingsprojekt. Det innebär att studien 
endast kommer involvera projektledare som har en teknisk bakgrund och inte involvera 
projektledare utan teknisk bakgrund. 


Fortsättningsvis kommer denna studie beröra projektledningen med fokus på den tekniska 
projektledaren inom en typisk projektledningsorganisation. 
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1.5 Våra definitioner av begrepp 


I detta avsnitt introduceras ett antal begrepp. Innebörden av dessa begrepp kan för vissa vara 
självklara medans för andra vara helt okända. Av den anledningen följer här en kort förklaring 
till vad de innebär baserat på teorier som presenteras i denna studie. 


IT-projekt 
I denna studie involverar IT-projektet nyutveckling av mjukvarusystem. Inom IT-projektet 
introducerar vi roller som programmerare, testare och drift och support. 


Teknisk projektledare 

Relativt tidigt introduceras begreppet teknisk projektledare. I studien är denna roll 
symboliserad av att vara projektledare över ett mjukvaruutvecklingsprojekt. Vidare innebär 
rollen ett ansvar över ett antal utvecklare samt ansvar för projektets fortskridande. (sektion 
2.1.2) 


Utvecklingsmetod och agil utvecklingsmetod 

Tlitteraturgenomgången kommer begreppet utvecklingsmetod ideligen att återkomma. Detta 
är en sorts metod som utvecklare genomför sin programmering/testning efter. Det 
övergripande ansvaret över denna metod kan tilldelas den tekniska projektledaren. En agil 
utvecklingsmetod innebär att utvecklingsarbetet utförs inkrementellt i iterationer. 
Kravställningen är inte fastställd i början utan kan komma att förändras under 
utvecklingsarbetet. (sektion 2.2.2) 


Utvecklare 

Genom hela denna studie kommer vi diskutera kring utvecklaren och dess roll. Med 
utvecklare menar vi de som implementerar själva systemet i form av systemdesign, 
programmering samt test. (sektion 2.2.3) 
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2 Litteraturgenomgång 


Detta kapitel tar upp vad som generellt definierar projektledning för att sedan belysa teorier 
om projektarbetens livscykel. Projektledningsteorin beskrivs inledningvis ur en generell 
synvinkel för att kort därefter fokusera kring IT-projekt. Kapitlet fortsätter med att beskriva 
projektledaren, både generellt och i mjukvaruindustrin. Därefter fortsätter 
litteraturgenomgången med kapitlet mjukvaruutveckling. Detta kapitel hanterar områden som 
mjukvarukvalitet, utvecklingsmetodik, samt mjukvaruutvecklingsroller. Det sista kapitlet 
handlar om kompetens. Här beskrivs vad begreppet kompetens innebär och sedan ges en 
beskrivning om hur kompetensutvecklingen sker. Vi har valt dessa områden eftersom de 
ligger till grund för vår forskningsfråga. Kapitlet avslutas med att lyfta fram vilka 
kompetensområden som är centrala för en teknisk projektledare. Litteraturgenomgången 
avslutas med att alla teoriområden sammanställs i vår undersökningsmodell. Här lyfts 
teoretiska samband upp mellan de olika teorierna som tidigare belysts. De formar sedan 
påståenden och frågor som presenteras i tabell 2.1 och tabell 2.2. 


2.1 Projektledning 


Inledningsvis vill vi reda ut vad projektarbete egentligen innebär. Detta kommer underlätta en 
senare fördjupning mot IT-projekt. Enligt Görling (2009) och Marcusson & Ahlin (2002) är 
ett projektarbete ett tillfälligt strävande att skapa en ny produkt, tjänst eller resultat. Något 
som vidare karakteriserar ett projektarbete är att den mänskliga kompetensen ska vara 
applicerbar för projektarbetets specifika syfte. (Görling, 2009) 


Görling (2009) och Macheridis (2005) är överens om att projektarbeten är unika när det 
kommer till dess temporära natur, de har en specifik början och ett specifikt slut. Målet med 
alla projektarbeten är att slutföra uppgiften. Vidare beskriver Görling (2009) att projektets mål 
utgår ifrån tre dimensioner (figur 2.1). 
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Figur 2.1 Projekttriangeln (modifierad efter Görling, 2009, s. 43) 


Det är en utmaning att uppfylla dimensionerna tid, funktion och ekonomi i ett och samma 
projektarbete (figur 2.1). Det är snarare mer realistiskt att uppnå två dimensioner samtidigt. 
Det är inte ovanligt med projektarbeten där kostnaden för projektarbetet är låg (ekonomi) 
tillsammans med att det som levereras är åtskilligt i sin omfattning (funktion). Om 
projektarbetets ägare sedan vill att dessa dimensioner ska kombineras med kort leveranstid 
(tid) så visar sig det vara en stor utmaning. Det kan tyckas vara ett i synnerhet intressant 
koncept då flertalet IT-projekt ofta resulterar i förseningar. (Görling 2009) 


2.1.1 Projektarbetens livscykel 


För att inledningsvis ge en bild av projektarbeten och hur de är uppbyggda ska projektarbetets 
livscykel betraktas närmare. Ett projektarbete kan beskrivas vara uppdelat i olika faser, dessa 
skapar tillsammans själva livscykeln. Det existerar idag många olika metodböcker som 
beskriver livscykeln av ett projektarbete, det kan bero på avsaknaden av en 
standardbeskrivning av hur ett projektarbetes livscykel ska vara utformad. Projektarbeten 
bedrivs på olika sätt i olika branscher, men inte heller inom branscherna finns en etablerad 
standard på hur projektarbetets livscykel ska vara utformat. (Kerzner, 2009) 


Vidare betraktas strukturen av ett IT-projekts livscykel på likartade sätt. Marcusson & Ahlin 
(2002) och Görling (2009) är nästan helt överens om hur IT-projektets livscykel är uppbyggd. 
Det som är positivt med den livscykelmetod som Marcusson & Ahlin (2002) använder är dess 
detaljerade utformning (figur 2.2). 
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Figur 2.2 Ett IT-projekts olika faser (modifierad efter Marcusson & Ahlin, 2002, s. 16) 


Kerzner (2009) hävdar att livscykeln för utvecklingsprojekt (IT-projekt) skiljer sig från andra 
projektarbetens livscykler. Anledningen till detta är att utvecklingsprojekt innefattar teknologi 
som snabbt blir föråldrad. Därför ter sig livscykelns tidsspann kortare för de projekt som 
omfattar mjukvaruutveckling. För att effektivt kunna driva dessa projektarbeten kan 
implementationen segmenteras och levereras i delar. Ett exempel på det är när företag vid 
tiden för en full implementation av ett utvecklingsprojekt redan hade hunnit utveckla en 
uppdaterad version. Lösningen på detta problem kan finnas i livscykelfaser som är kortare, det 
finns även möjligheter att lösa problemet med att segmentera implementationen och leverera 
produkten i mer distinkta delar. (Kerzner, 2009) 


Enligt Kerzner (2009) visar en förekommande trend på att fler och fler företag försöker 
anpassa sitt arbete i projekt efter en strukturerad livscykel. Det påstås finnas anledningar för 
dessa trender. För det första kan tydliga avgränsningar för varje livscykelfas fastställas, vilket 
gör arbetsuppgifterna mer distinkta för projektets deltagare. Fortsättningsvis blir då 
tidsestimering samt prissättning av projektets uppgifter mindre komplexa. Slutligen 
underlättas även fortlöpande projektfinansiering eftersom livscykeln för med sig naturliga 
tillfällen för tidsmässigt strategiska beslutstillfällen. (Kerzner, 2009) 


Som nämnt tidigare skiljer sig livscykelfaserna för mjukvaruutvecklingsprojekt från andra 
projekts livscykelfaser, exempelvis projekt inom tillverkningsindustrin. Figur 2.3 beskriver 
överskådligt och utan fördjupning vilka faser som ingår i den förstnämnda livscykeln. 
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Figur 2.3 Ett mjukvaruutvecklingsprojekts livscykel (modifierad efter Kerzner, 2009, s. 73) 


Projektets livscykel har fler användningsområden då det är projektledarens huvudsakliga 
redskap (Wohlin, 2005). I nästa avsnitt kommer projektledaren beröras mer ingående. 


2.1.2 Projektledaren 


För att ett projekt ska kunna genomföras och för att alla inblandade ska veta vilka deras 
uppgifter är behövs en projektledare. Vidare ska projektledaren ansvara för att samordna och 
integrera de inblandade verksamheterna över flera funktionella linjer. Det betyder att 
projektledaren är huvudansvarig för att under projekttiden behålla kommunikationen mellan 
alla intressenter (figur 2.4). Dessa intressenter är oftast representerade som projektets sponsor, 
projektteamet samt andra intressenter som är involverade. (Kerzner, 2009). Figur 2.4 visar 
projektledaren i en typorganisation av ett projekt. 
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Figur 2.4 Typorganisationen av ett projekt enligt den svenska standarden SIS TR 321 (modifierad efter 
SIS — Standardiseringskommissionen i Sverige, 1989 enligt Marcusson & Ahlin, 2002, sid 25) 


Enligt Wohlin (2005) består arbetsuppgifterna för en IT-projektledare av att skapa och 
förvalta en projektplan, rekrytera de resurser som är nödvändiga för projektet och skapa en väl 
anpassad tidsestimering för projektet. Vidare måste också en riskhanteringsplan skapas. 
Förutom dessa ansvarsområden är det upp till projektledaren att regelbundet rapportera om 
projektets fortskridande till besluts- och referensgrupp (figur 2.4). 
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Tekniska projektledare inom mjukvaruutvecklingsindustrin har blivit allt vanligare under de 
senaste åren. Jämsides med den tekniska utvecklingens fortsatta framfart har komplexiteten 
för att leda dessa projekt ökat. Det introduceras kontinuerligt nya ramverk, 
programmeringsspråk och metoder för att utveckla, dessa ställer nya krav på den tekniska 
projektledaren. Ett exempel är frågan om vilken utvecklingsmetod verksamheten ska tillämpa, 
ska det vara den traditionella vattenfallsmetoden eller en agil utvecklingsmetod? Många 
verksamheter använder idag en agil utvecklingsmetod som Scrum och Test-driven 
development (TDD). (Jalote, 2002; Hughes & Cotterell, 2009) 


Fortsättningsvis ställer detta krav på att tekniska projektledare ska ha kunskap om hur arbetet 
enligt dessa metoder ska utföras. Andra egenskaper som den tekniska projektledaren 
vanligtvis har är den tekniska problemlösningen. I dessa fall kan en teknisk projektledare med 
hjälp av sitt tekniska kunnande förstå roten av problemet samt uppskatta den tid samt den 
kostnaden problemet kommer att kräva. (Jalil & Shahid, 2008) 


Thamhain och Wilemon (1979) uppmärksammar också detta fenomen angående den tekniska 
projektledaren, speciellt förmågan att bedöma risker och kommunicera med projektteamet. En 
förutsättning för att leda ett utvecklingsprojekt är att kunna kommunicera med projektets 
deltagare, i detta fall utvecklarna. Arbetet i utvecklingsprojektet kräver tekniskt inriktade 
dialoger mellan projektets deltagare och den tekniska projektledaren, dessa sorts dialoger är 
naturliga för den tekniska projektledaren. (Thamhain & Wilemon, 1979) Enligt Jalil & Shahid 
(2008) är dock den viktigaste aspekten hos den tekniska projektledaren att de kan översätta de 
problem utvecklarna träffar på i projektet för de mindre tekniskt inriktade intressenterna (figur 
2.4). 


Vidare är det också intressant att ta upp vad Jalil & Shahid (2008) skriver om projektledare 
som inte innehar en teknisk kompetens. Tidigare betraktades det strategiskt att utse den mest 
tekniskt kompetenta inom projektgruppen som projektledare. Anledningen till detta påstår 
Jalil & Shahid (2008) var att den tekniska kompetensen projektledaren hade underlättat för 
resterande utvecklare i gruppen att nå målen. Det visar sig dock att projekt som leds av 
tekniska experter oftare misslyckas till följd av dålig projektstyrning. Detta beror ofta på att 
den tekniska projektledaren fokuserar för mycket på lösningarna av de tekniska problemen än 
på övergripande projektproblem. Kommunikationsegenskaper nämns också som ett vanligt 
problem för de med teknisk expertis. Denna risk får inte försummas eftersom det annars kan 
leda till stora problem. Icke-tekniskt kompetenta projektledare kan dock också fatta inkorrekta 
beslut berörande tekniska problemen. (Jalil & Shahid, 2008) 


2.1.3 Projektledare inom mjukvaruindustrin 


Brooks (1987) hävdar, att det finns olika karaktärsdrag som kännetecknar ett 
utvecklingsprojekt, vilka i sin tur ställer krav på projektledaren. Aktiviteterna i ett 
utvecklingsprojekt kan klassas som osynliga. Det innebär att det inte går med ett rent 
betraktande urskilja hur framstegen ter sig. Det är i denna omgivning projektledaren ska verka 
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för att göra det osynliga mer förståeligt för projektets intressenter. Projektledare för 
utvecklingsprojekt arbetar enligt Brooks (1987) i en mycket komplex miljö. Det blir i 
slutändan projektledarens ansvar att alla inblandade i projektet har den förståelse som krävs 
för att de ska kunna genomföra sitt arbete. En mjukvaruprojektledare har också i uppgift att 
omvandla kundernas och deras organisations krav. Det är kundernas uppfattning om hur 
slutprodukten kommer se ut som mjukvaruprojektledaren sedan ska omvandla till aktiviteter 
för utvecklarna. Dessa krav är dock beroende av att kundens krav inte ändras under tiden. 
Slutligen kännetecknas utvecklingsprojekt som flexibla vilket också resulterar i att de allt som 
ofta ska anpassas mot organisationens mål. Ställs däremot förhållandet omvänt, att 
organisationen ska anpassas mot IT finns där inte samma flexibilitet. Detta problemområde 
inkluderar också mjukvaruprojektledaren som är högst ansvarig för exempelvis 
implementationen av ett nytt system på ett företag. (Brooks, 1987) 


En ständigt återkommande slutsats i studier och i litteratur om utvecklingsprojekt är deras 
fortsatta tendens att misslyckas. Antingen genom att projektet blir försenat, går utanför 
budgetens ramar eller att det läggs ned. Denna trend har under många år varit negativ där 
antalet misslyckade projekt ökat, detta visar The Standish Group” i sin rapport från 2009. En 
studie presenterad 2009 visar att ungefär en tredjedel (32 90) av alla utvecklingsprojekt 
misslyckas och lades ner, 44 90 blev försenade eller gick utanför den utsatta budgeten. Det 
förmodligen mest anmärkningsvärda angående utvecklingsprojekten är att nästan en fjärdedel 
av dem aldrig slutförs eller aldrig används. (Standish group chaos report, 2009) 


Det har blivit mer vanligt att organisationen som driver ett IT-projekt, hyr in en extern teknisk 
projektledare. Med sin tekniska kompetens möter den tekniska projektledaren organisationens 
egna utsatta projektledare som har kunskap om organisationens mål. Därefter ansvarar den 
tekniska projektledaren över själva projektledningen samt över de tekniska frågorna. (Hughes 
& Cotterell, 2009) 


2.2 Mjukvaruutveckling 


Andersen (1994) hävdar att mjukvaruutveckling är den process där framtagandet samt 
skapandet av ett nytt informationssystem sker. Även Wiktorin (2003) diskuterar ämnet och 
nämner i sin tolkning av systemutveckling vikten av att systemet skall stödja verksamhetens 
informationshantering. Framtagandet av ett informationssystem är själva 
systemutvecklingsprocessen enligt Andersen (1994). 


Det som karaktäriserar ett informationssystem är att det är en mänsklig konstruktion, dvs. 
både hur det är uppbyggt och hur det fungerar. Ett informationssystem har alltid en uppgift att 
lösa och detta görs främst genom förmedling av information mellan olika parter som använder 
informationssystemet. Den information som strömmar genom informationssystemet 


? En Amerikansk organisation dedikerade åt bland annat mätning av misslyckade utvecklingsprojekt 
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behandlas ofta av systemet, det kan vara allt ifrån olika beräkningar till att presentera data på 
ett mer lättförståeligt sätt mot användare. Behandlingen av data behöver inte bara ske 
maskinellt utan även manuellt, vilket innebär att människor kan vara inblandade i processen 
av ett informationssystem. Detta är mycket viktigt att ta hänsyn till under konstruktionen av 
ett informationssystem då det stödjer människans roll och behov. (Andersen, 1994) 


2.2.1 Mjukvarukvalitet 
Wohlin (2005) nämner kvalitet enligt citat 


”Kvalitet är ett relativt begrepp, det vill säga det beror på omgivningen och 
förutsättningarna” (s. 183) 


Kvalitet har en bred mening och inom mjukvaruutveckling handlar det om att möjliggöra för 
vidareutveckling av systemet som levereras, och inte bara leverera kundens krav och 
önskemål. Genom en god kvalitet underlättas vidareutveckling samt underhåll av systemet. 
Ett sätt att definiera kvalitet är med hjälp av International Standardization Organization (ISO). 
ISO-standarderna består av flera fördefinierade attribut, som exempelvis användbarhet, 
underhållbarhet. Dessa attribut är till för att ge stöd i arbetet med kvalitet. (Wohlin, 2005) 


Attributen har i sin tur flera olika subattribut för ytterligare stöd. Även Wiktorin (2003) 
nämner användningen av ISO-standarderna som är uppbyggda av ett kvalitetssystem. ISO- 
standarderna har som roll att se till att utföra vissa uppgifter som genererar god kvalitet, 
exempelvis att dokumentationen sköts. Vidare poängterar Wiktorin att ISO-standarderna är en 
bra start för definition av det arbete som bör utföras för att kvalitet skall uppnås. ISO- 
standarden 12207 heter den som används inom programvaruutveckling och denna ISO- 
standard heter i Sverige: Livscykelprocesser för programvara. (Wiktorin, 2003) 

Även Andersen (1994) nämner kvalitet, fast han väljer att definiera det enligt följande: 


”Kvalitet är överensstämmelsen mellan ett färdigt informationssystem och de förväntningar 
användarna har på det. God överensstämmelse betyder god kvalitet och dålig 
överensstämmelse innebär dålig kvalitet.” (s. 469) 
För att nå god kvalitet krävs att projektgruppen tidigt i utvecklingsarbetet tar till sig kvalitet 
och jobbar med kravformulering (Wiktorin, 2003). 

2.2.2 Utvecklingsmetodik 


Wiktorin (2003) beskriver utvecklingsmetodik enligt citat: 


”En utvecklingsmodell delar in utvecklingsarbetet i ett antal faser och anger i vilken ordning 
dessa skall utföras. Mellan faserna placeras avstämningspunkter”. (s. 30) 
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Wohlin (2005) menar att utvecklingsmetodik (som han har valt att kalla utvecklingsprocesser) 
har mycket gemensamt med en produkts livscykel (sektion 2.1.1). Alla olika metoder 
(processer) har samma uppbyggnad med kravställning som första punkt följt av utveckling 
och test av programvaran och avslutningsvis leverans av programvaran. 

En av de mest frekvent använda utvecklingsmetodiken är Vattenfallsmodellen. Den är 
uppbyggd så att den går från fas till fas. Projektarbetet har då aldrig möjlighet att gå tillbaka 
till en avslutad fas. Detta kan liknas vid en nedåtgående trappa. I denna modell får därför 
aldrig projektarbetet gå tillbaka till en avslutad fas. (Wohlin, 2005) 


Inkrementell utveckling handlar om att definiera olika inkrement, som skall uppnås och 
levereras i olika delar. Dessa leveranser skall sedan testas och detta görs med fördel parallellt 
som nya inkrement utvecklas. Utvecklingen av inkrementen sker ofta med hjälp av 
vattenfallsmodellen, men tack vare inkrementen blir det mindre leveranser, och mindre att 
testa. (Wohlin, 2005) 


Wohlin (2005) anser att agil utveckling handlar om att skapa en metodik som är snabb och 
flexibel till skillnad från tidigare utvecklingsmetoder som är oflexibla och långsamma. 
Vanligt förekommande metod som använder sig av agil utveckling är XP (Extreme 
Programmering) och Scrum. Görling (2009) nämner att det under senare år har vuxit fram 
flera agila metoder. Största anledningen till framväxten av dessa metoder är att de äldre 
metoderna ofta innebar svårigheter för projektledaren att definiera vad som skulle utvecklas 
och därefter låta programmerarna utveckla. I stället använder projektledarna sig av de agila 
metoderna så är alla parter (utvecklare, projektledare, kunder) med och jobbar ihop genom 
utvecklingen. Då kunder inte alltid vet vad de vill ha samt att utvecklingen inte alltid går att 
fördefiniera förespråkar det agila tänket att projektarbetet jobbar i korta cykler. Detta medför 
att förändringar i kravställningen snabbt och lätt kan hanteras. (Görling, 2009) 


Scrum är en av de vanligaste metoderna inom agil utveckling. Tanken bygger på att 
projektgruppen inte vet hur de tar sig från uppstart till färdig produkt utan att kontinuerligt 
jobba iterativt. Inom Scrum existerar fördefinierade roller och projektarbetet jobbar i så 
kallade sprintar som är iterationer som oftast ligger på 30 dagar. Inom Scrum finns det ingen 
som bestämmer utan det är ett kollektivt ansvar vad som levereras. (Görling, 2009) 


Test-driven development (TDD) är en metod som fokuserar på tester och definierar de tester 
som skall vara avklarade för varje iteration. När en iteration är färdig börjar projektarbetet 
definiera de nya testerna som skall uppnås och så fortlöper det. (Görling, 2009) 


Under utvecklingen av ett system bör hänsyn tas till människa-datorinteraktionen. Människa- 
datorinteraktion kan beskrivas som designen/framtagningen av en produkt för att stödja 
kommunikationen mellan olika människor i deras vardagliga liv. Grundidén är att skapa en 
produkt som både förbättrar och effektiviserar sättet vi jobbar och kommunicerar på. (Preece, 
Rogers & Sharp, 2007) 
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2.2.3 Mjukvaruutvecklingsroller 
Ett mjukvaruprojekt består ständigt av ett flertal olika roller. De vanligaste rollerna är: 


Utveckare är en av dessa roller som oftast har i uppgift att implementera systemet. 
Utvecklarrollen kan bli nedbruten i subkategorier som systemdesigner, programmerare, men 
utvecklare kan vara ansvariga för bägge dessa subkategorier. Utvecklare kan även utföra 
tester, men i många fall finns specifika testare. (Wohlin, 2005) 


Testare genomför tester av olika funktioner och system. Testarna kan vara utvecklare men vid 
större projekt är det oftast specifika personer med enbart rollen som testare. Deras jobb består 
utöver själva testandet att även att ta fram testspecifikationer. (Wohlin, 2005) När 
applikationen är färdig skall den driftsättas. 


Då tar driftpersonalen vid och gör själva utrullningen av applikationen. Detta sker i samarbete 
med utvecklarna samt de kvalitetsansvariga för att säkra en stabil utrullning. Denna 
driftsättningsprocess beskrivs i detalj i figur 2.5. Driftpersonalen är sedan ansvarig för driften 
av denna applikation. (Görling, 2009) 


Driftsättningsprocessen 


Utveckling Test / OA Drift 


Policier Paketering Implementering 
Releaseplanering Konfiguration Verifiering 
Arkitektur Kvalitetsgranskning 
Integration Godkännande 
Be Corren 


Figur 2.5 Driftsättningsprocessen (modifierad efter Görling , 2009, sid 202 2009, sid 202) 


2.3 Kompetenser 


Oftast beskrivs kompetens som en output av kunskap som är dess respektive input 
(Uggelberg, 1986). Kompetens anses inte bara kunna utvinnas från kunskap. Det ses snarare 
som ett samspel mellan olika egenskaper, erfarenheter och färdigheter som en person har. 
(Nilsen & Högström, 1994) Redogörelse för vilken sorts kompetens som tekniska 
projektledare behöver kommer i följande avsnitt. 
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2.3.1 Utvecklingen för att bli kompetent 


För att med rättvisa kunna förklara begreppet kompetens vill vi först ge ett förtydligande om 
olika sorters kunskap. Det existerar olika sorters kunskap. Hantverkare har oftast så kallad 
embodied knowledge, kunskap som är förkroppsligad genom praktik. En matematiker har 
embrained knowledge, vilket oftast är ett uttryck av konceptuella och kognitiva egenskaper. 
(Walsham, 2001) 


Vidare för att beskriva kompetens så vill vi framhålla den franske filosofen Denis Diderot 
som särskiljer mellan teoretiskt och praktiskt erhållen kunskap (Hoberg, 1998). För att påvisa 
skillnaden mellan teoretisk och praktisk kunskap följer här två citat från Hoberg (1998) varvid 
den första är ett uttalande gjort av Diderot. 


”För att veta vad det är att baka ett bröd måste man någon gång ha knådat en deg” (s. 11) 
”Det är praktiken som ger de teoretiska kunskaperna liv” (s. 13) 


Vilka exakta kunskaper som en teknisk projektledare har användning av presenteras senare i 
litteraturgenomgången (sektion 2.3.3). Dreyfus och Dreyfus (1986, enligt Hoberg 1998) finns 
det fem steg i yrkeskunnandet av en systemutvecklare. Vi har som mål att klargöra vad som 
förknippas med kompetens inom ovan nämnda branschinriktning och för att underlätta det 
presenteras därför dessa steg: 


1. Novis 

2. Nybörjare 
3. Kompetent 
4. Skicklig 

5. Expert 


Som det framgår i listan ovan används benämningen kompetent om någon som inte är 
fullfjädrad i sin kunskapsutveckling (Dreyfus & Dreyfus, 1986, enligt Hoberg 1998). För att 
göra det möjligt med en rik beskrivning av vad begreppet kompetens innebär följer här en mer 
detaljerad beskrivning över de fem stegen i yrkeskunnandet för en systemutvecklare. 


Det förekommer mer än en definition på vad kompetens är och huruvida någon är kompetent 
för en specifik tjänst. Här följer en beskrivning som uteslutande baserats på yrkeskunnande 
för att handskas med begreppet kompetens. Det första steget i utvecklingen av yrkesmässiga 
kunskaper benämns novis. En novis är en debutant inom ett nytt område. Det kan påstås att 
denna person blir introducerad för okänd fakta och regler. Något som mer precist definierar 
novisen är att av de regler som han eller hon introduceras för, är det ett begränsat antal som 
novisen lyckas bemästra. (Dreyfus & Dreyfus 1986, enligt Hoberg, 1998) 


Nästa steg är nybörjare. När en individ börjar utsättas för verkliga situationer med 
branschspecifika element som exempelvis arbetet i en ny systemmiljö börjar individens 
erfarenheter växa. Då ökar individens förmåga att behandla både situationella och 
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sammanhangsfria element, detta formar sig sedan som en undermedveten praxis för individen. 
(Dreyfus & Dreyfus 1986, enligt Hoberg, 1998) 


När individen fortsätter att utvecklas bortom gränserna för en nybörjare ökar också individens 
spektrum för den mängd element som existerar i den branschspecifika kontexten. Något som 
då utmärker en individ som innehar ett kompetent yrkeskunnande är förmågan att avgränsa 
sig med stöd av en organisationsplan. Det kan beskrivas som att kunskaperna befinner sig på 
en nivå som tillåter individen att själv kunna påverka utkomsten av det åtagande individen 
involverar sig i. Detta kan då med fördel göras med en organisationsplan. Den tankeprocess 
som en kompetent individ har kan därför med fördel förknippas med tankeprocessen för 
problemlösning. En individ som bemästrat kompetens kring ett specifikt område är således i 
slutfasen av sitt lärande. De två efterföljande tillstånden av yrkeskunnande, skicklig och 
expert kommer inte beröras i detalj eftersom det är tillståndet kompetent denna studie ämnar 
undersöka. Efter att ha uppnått tillståndet kompetent kan individen endast bli mer kompetent. 
(Dreyfus och Dreyfus 1986, enligt Hoberg, 1998) 


2.3.2 Centrala kunskapsområden för tekniska projektledare 


I en studie genomförd av Lee, Trauth & Farwell (1995) uppmärksammas fyra kategorier av 
kompetensområden. Dessa har tagits fram med hjälp av litteratur, gruppdiskussioner och 
intervjuer och syftar till att fastställa vilka de viktigaste kunskaperna är för chefer inom 
Information Systems (IS) branschen. Resultatet visade att de fyra viktigaste kunskapsområden 
var: 


e Tekniska specialiteter 
e Teknisk ledning 

e Verksamhetsfunktioner 
e Relationer och ledning 


De tekniska specialiteterna är viktiga på grund av att tekniken förnyas snabbt. Tekniska chefer 
är också i behov av kunskap om hur IT ska distribueras på ett sätt som möter verksamhetens 
mål, så kallad teknisk ledning. Detta inkluderar förmågan att lära sig nya teknologier samt att 
använda dessa som ett medel men inte som ett mål. Vidare behöver tekniska chefer kunskaper 
om verksamheternas olika funktioner för att kunna realisera verksamhetens mål med hjälp av 
IT. Detta innebär att förstå och lära sig verksamhetens olika funktioner samt förstå dess 
omgivningar. Kunna tolka verksamhetens olika problem för att vidare kunna applicera 
lämpliga tekniska lösningar, ihop med kunskapen om mänskliga relationer är även det viktiga 
egenskaper för de tekniska cheferna. Behovet av kunskaper om mänskliga beteenden för 
appliceringen av IT-stöd för att vinna acceptans från slutanvändarna av systemet. (Lee, Trauth 
& Farwell, 1995) 
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2.4 Undersökningsmodell 


Med de presenterade teoretiska områdena ska nu studiens undersökningsmodell introduceras. 
Undersökningsmodellen utgår från teoriområdet kompetens, som i modellen utformats vidare 
från tidigare nämnda franske filosofen Denis Diderots teorier om teoretiskt och praktiskt 
erhållen kunskap (Dreyfus och Dreyfus, 1986 enligt Hoberg, 1998). Dessa teorier 
uppmärksammas vidare av Ellström (1992) enligt Andersson, Sjösten & Ahn (2003). De 
beaktar skillnaden som existerar mellan reell kompetens (faktisk kompetens), vilket erhålls 
från arbetslivet samt formell kompetens som erhålls från utbildning (figur 2.6). Samtidigt som 
den formella kompetensen inte överensstämmer med den faktiska kompetensen råder liknande 
förhållande mellan kompetens som gör någon kvalificerad för en arbetsuppgift. (Dreyfus och 
Dreyfus, 1986 enligt Hoberg, 1998) 


Dessa kvalifikationskrav formas av arbetsmarknaden och kan påverkas av exempelvis 
konjunkturen (Ellström, 1992 enligt Andersson, Sjösten & Ahn, 2003). Slutligen möts 
kompetens och kvalifikation vilket urskiljer den uppfattade kompetensen vilket citerat från 
Ellström (1992) enligt Andersson, Sjösten & Ahn (2003) är: 


”Den kompetens individen faktiskt har och som dessutom kommer till användning” (s. 37) 


Som det framgår i figur 2.6 innehåller undersökningsmodell ytterligare två ämnesområden 
(mjukvaruutveckling och projektledning). Dessa bidrar med själva forskningsinriktningen. 
Inriktningen kombineras sedan med förhållandet mellan kompetens och kvalifikation. 
Kombineringen av teoriområdena fördelas sedan i kategorier som resulterar i fyra påståenden 
samt fyra frågor. Påståendena har teoretiskt stöd medan frågorna ställs direkt mot empirin och 
därför saknar teoretiskt stöd. Påståendena och frågorna utgår från teoretiska områden vilket 
slutligen presenteras i tabell 2.1 och tabell 2.2. 
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KOMPETENS & KVALIFIKATION 


Formell Efterfrågad 
kompetens kompetens 


SS Utnyttjad 4 | 


kompetens 


Faktisk / Den kompetens 
kompetens som arbetet 
kräver 


MJUKVARUUTVECKLING PROJEKTLEDNING 
Programmering Projektledningsutbilding 
Drift/Server Projektledningserfarenhet 
Testning Teknisk projektledning 


Utvecklingsmetodik Projektets livscykel 
Människor-Data Interaktion 


Mjukvaruarkitektur 


Figur 2.6 Studiens undersökningsmodell 


2.4.1 Samband mellan de teoretiska områdena 


I detta avsnitt kommer de tre teoretiska områdena sammanföras på ett sätt som illustreras i 
figur 2.6. Detta leder till påståenden och frågor som kan ses i tabell 2.1 samt tabell 2.2. 
Påståendena grundas på teoretiskt stöd som uppmärksammats i kapitel 2. Frågorna har vi 
utformat efter vilka områden vi inte fick svar på med hjälp av teorin. Dessa ligger som grund 
för att besvara vår forskningsfråga och har framkommit under diskussioner sinsemellan. 


Förklaring till påståendena presenterade i tabell 2.1 

Påstående ett grundar sig på teorier Jalil & Shahid (2008) har angående teknisk kompetens 
hos tekniska projektledare. Påstående två utgår ifrån vad Crawford (2000) skriver angående 
det ökade intresset för projektledningsutbildning. Detta påstående har lyfts fram utan att 
explicit stödjas i litteraturgenomgången (delkapitel 1.1). Vidare bygger påstående tre på Lee, 
Trauth & Farwell (1995) teorier om tekniska chefers ansvarsområden (sektion 2.3.3). 
Slutligen ställs påstående fyra med utgångspunkt från livscykelteorier Kerzner (2009) påvisar 
(sektion 2.1.1). I tabell 2.1 har dessa påståenden sammanställts. 
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Förklaring till frågorna presenterade i tabell 2.2 

Vi har även sammanställt frågor som vi inte tydligt fått svar på genom vår teori och vill 
utforska med hjälp av vår empiri. Dessa frågor finns i tabell 2.2. Fråga ett utrönar kopplingen 
mellan projektledaren och dess tekniska kunnande. Fråga två undersöker projektledarens 
kommunikativa förmågor. Vidare på fråga tre går vi djupare med vilka specifika kompetenser 
som kan vara viktiga att inneha som tekniska projektledare. Fråga fyra undersöker vilka 
kompetenser som ofta saknas hos de tekniska projektledarna. 


Tabell 2.1 Sammanställning av påståenden grundad på teorin 


Nr Påstående 


1. | Teknisk kompetens behövs för att kunna verka i rollen som teknisk projektledare 


Projektledningsutbildning behövs för att stärka den formella kompetensen hos tekniska 
projektledare. Efter genomförd utbildning kan efterfrågad kompetens ha uppnåtts. 


3. | En teknisk projektledare ska kunna kombinera tekniska kunskaper med egenskaper att kunna 
leda och hantera arbetsteam. 


4. | Vari projektets livscykel de tekniska kunskaperna är av störst vikt varierar från projekt till 
projekt och från en branschinriktning till en annan. 


Tabell 2.2 Sammanställning av frågor grundad på teorin 


Nr Fråga 


1. | Vilka tidigare tekniska erfarenheter behöver en teknisk projektledare? 


Hur förhåller sig kommunikationen mot beställare samt utvecklare ur en teknisk projektledares 
synvinkel? 


3. | Vilka av följande kompetenser anses vara viktigast hos en teknisk projektledare: 
Mjukvaruarkitektur, Djup programmeringskunskap, Goda kunskaper om utvecklingsmetodik, 
Kunskaper inom människa dator interaktion och Mjukvarukvalitet? 


4. I Vilka kompetenser saknas ofta hos en teknisk projektledare, samt vilka kompetenser behöver 
dem generellt förbättra? 
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3 Metod 


3.1 Arbetsmetod 


Till en början tydliggörs det att förutsättningen för denna studie är vårt intresse för 
projektledning och mjukvaruutveckling. För att undvika risken att redan från studiens start 
ligga efter med planeringen inleddes diskussioner om ämnet redan hösten 2010. Nu i 
efterhand finns en påtaglig tacksamhet för denna goda framförhållning. Detta har möjliggjort 
att mycket tid har kunnat disponeras på att erhålla en så omfattande litteraturbas som möjligt. 


I arbetet med studien har en arbetsfrämjande struktur eftersträvats. Likt den agila 
mjukvaruutvecklingsmetoden Scrum, har arbetet med studien genomförts efter en kort men 
ändå preciserad planering. Arbetstiden struktureras upp i intervall av en timme och 
åskådliggörs sedan för varandras betraktande. Arbetsrisker som arbetsflykt kan därmed 
motverkas vilket resulterar i att onödiga avbrott begränsas. 


Ämnesval 


Bred 
litteratursökning 
och läsande 


Preliminär problemformulering 


Tankeskrivande 


Målinrikad 
litteratursökning 


Läsande och skrivande 


Feedback på 
utkast 
av Handledare 


Slutgiltig problemformulering 


Disposition 


L> 


Revidering 


Figur 3.1 Skrivprocess som vi har använt i arbetet med studien (modifierad efter Reinecker & 
Jeorgensen, 2008 s. 81-82) 
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Fortsättningsvis har själva skrivprocessen skett enligt den ”nya skrivprocessen”. Det innebär 
att arbetsprocessen följer ledorden ”skriv först och revidera efteråt”. Vi valde denna metod 
eftersom den passade vårt arbetssätt bättre än en gammeldags skrivprocess som involverar att 
planera och disponera innan skrivandet startar. Orsaken till detta angreppssätt är vår 
oerfarenhet av att skriva uppsats på denna nivå. Den nya skrivprocessen underlättar 
skrivandet. (Reinecker & Jörgensen, 2008); (figur 3.1). 


3.2 Den empiriska undersökningen 


3.2.1 Intervjufrågor 


Syftet bakom intervjuerna var att ta reda på en teknisk projektledares kompetensområden 
inom privata företag. Därför valdes frågor som berör informanternas yrkesmässiga bakgrund, 
vilka kunskaper inom projektledning som informanten anser mest relevant för en teknisk 
projektledare samt tekniskt inriktade frågor. Slutligen vill vi ha informanternas åsikt om 
vilken kompetensnivå som krävs av den tekniska projektledarrollen, exempelvis vilka 
områden kring mjukvaruutveckling det är viktigast att ha kompetens inom. 


De kategorier intervjufrågorna (tabell 3.1) delades in i syftar till att hänvisa till 
undersökningsmodellens olika teoriområden. De tre frågor som intervjuerna inleds med är 
från kategorin bakgrund och avser att ge informanten en naturlig och avslappnad start på 
intervjun vilket är av stor betydelse enligt Andersson (1994). Vidare anspelar fråga två och tre 
på vilka arbetsuppgifter en teknisk projektledare har samt vilken yrkesmässig bakgrund som 
är av störst betydelse för en teknisk projektledare. 


Intervjukategorin därefter behandlar projektledning. Dessa frågor eftersträvar att framhäva 
vilka projektledningskunskaper som är väsentliga för en teknisk projektledare. Andra frågor i 
denna intervjukategori bearbetar under vilken fas av projektet som den tekniska 
projektledarens roll är som mest uppmärksammad följt av frågor om en 
projektledningsutbildning som genomförts av informanten. Det intressanta i denna fråga är 
om utbildningen bidragit till informanternas förmåga att driva tekniska projekt. Den 
avslutande frågan i denna kategori riktar sig mot informanternas projektledarkunskaper och i 
synnerhet om informanten anser sig sakna någon specifik kompetens som teknisk 
projektledare. 


Den avslutande kategorin i intervjuunderlaget behandlar ämnet kompetens. Frågorna som 
ingår i denna kategori betonas av vilka yrkesmässiga kompetenser inom teknisk 
projektledning som är av störst betydelse. Informanten får rangordna givna kompetenser efter 
vilken som är viktigast i deras roll (bilaga B1). Intervjun avslutas med frågan som ska reda ut 
vilka kompetenser informanten anser sig sakna. Vi anser att det är intressant att utreda om det 
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finns någon koppling mellan informanternas kompetenser, både kompetenser de redan har och 
de kompetensområden som kan utvecklas. 


Tabell 3.1 har vi strukturerat det empiriska materialet i kategoriform. Denna kategorisering 
har utgått ifrån studiens tre teoriområden projektledning, mjukvaruutveckling och kompetens. 


Tabell 3.1 Översikt av intervjukategorier och frågor 


Kategori Åmne 

Projektledning 1.1 Tidigare projektlednings erfarenheter 
1.2 Vilken fas av projektets livscykel är de tekniska kunskaperna av störst 
vikt/betydelse? 


1.3 Genomgått någon form av projektledningsutbildning i tjänsten? 
1.4 Avsaknad av några specifika projektledaregenskaper i syfte att höja sin 
kompetens som teknisk projektledare? 


Mjukvaruutveckling | 2.1 Vilken teknisk kompetens är relevant för en teknisk projektledare? 


2.2 - Bör tekniska projektledare ha erfarenhet av: programmering, test, drift 
och support samt eftermarknad? 

2.3 - Hur förhåller sig en teknisk projektledare i kommunikationen med 
beställare och utvecklare? 


Kompetens 3.1 Erfarenhet av att jobba som utvecklare? 

3.2 Vilka kompetenser är viktigast för att kunna bedriva ett tekniskt projekt? 
3.3 Någon kompetens som vidare kan utvecklas för att bli en bättre teknisk 
projektledare? 


3.2.2 Intervjuer 


Den metod som utformades för att på bästa sätt besvara forskningsfrågan grundade sig i att 
hitta informanter inför en kvalitativ strukturerad intervju. Enligt Andersson (1994) innebär en 
strukturerad intervju att frågor och frågeområden samt i vilken ordning frågorna ställs, på 
förhand är definierat. Detta kan i många fall förhindra möjligheterna att få en naturlig dialog 
mellan intervjuare och informanter (Andersson, 1994). 


Det vi eftersträvade med intervjuerna var att från början ha frågorna klara för oss. Det 
strukturerade sättet vi arbetade efter krävde en intervju som till viss del också var 
strukturerad. Det vi menar då är att även om intervjuerna på förhand var upplagda för en 
strukturerad intervju eftersträvades en avslappnad stämning under intervjuerna. I detta fall 
betyder det att naturliga följdfrågor var tillåtna att förekomma. Genom att på förhand 
formulera frågor tillsammans med de följdfrågor vi förmodade frågorna skulle generera i. På 
det sättet effektiviserade vi själva intervjun utan att kvalitén blev lidande. Ytterligare en 
anledning till att vi strävade mot att ha intervjuerna färdigformulerade på förhand var bristen 
av informanternas lediga tid. För att underlätta för informanten samt höja kvalitén på svaren, 
skickades frågorna ut en vecka innan intervjun. Till denna studie lämpade sig intervjuformen 
bättre än enkätformen av den anledningen att förtydliganden, mindre omformuleringar och 
upprepningar kunde ske på vår och informanternas begäran. (Andersson, 1994) 
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För att säkerställa intervjuunderlagets kvalitet tillämpades två olika metoder. Dels påbörjades 
arbetet med den empiriska delen i ett tidigt skede för att vid flertal tillfällen kunna erhålla 
feedback angående underlagets kvalitet från handledaren. Dessutom ansåg vi att det fanns 
utrymme för en förstudie beträffande intervjuunderlagets kvalitet. Detta innebar att 
intervjuunderlaget skulle granskas av en utomstående person som inte var delaktig i 
intervjuerna. Syftet med denna förstudie var att se till att intervjumaterialet höll hög kvalitet. 
Inför intervjuerna skulle alla informanter delges hela intervjuunderlaget med samtliga frågor. 
Dessutom skulle alla informanter också erhålla ett dokument innehållande 
begreppsdefinitioner. Detta skulle fungera som stöd till de begrepp som användes i 
intervjufrågorna. Många begrepp kan anses breda, exempelvis kan olika informanter ha olika 
uppfattningar av vad en teknisk projektledare är. Dokumentet med begreppsdefinitionerna 
syftade till att öka informanternas möjlighet, att enligt våra definitioner, svara på frågorna 
korrekt. Ytterligare förberedelser som genomfördes var att ta hänsyn till så kallade ”probes” i 
intervjun (Andersson, 1994). Probes kan beskrivas som intervjuteknik som syftar till att stödja 
och uppmuntra informanten att lämna ett så fullständigt svar som möjligt. Probes användes 
också för att informanterna skulle trivas i intervjusituationen. (Andersson, 1994) 


Vi var överens om att intervjuformen passade bättre än enkätformen i vårt speciella avseende. 
Det berodde på att flera begrepp i intervjufrågorna med största sannolikhet behövde redogöras 
vilket intervjuformen tillåter. Informanterna skulle delges en dokumentation en tid före 
intervjun med definitioner av de begrepp som vanligtvis kan tolkas på olika sätt, exempelvis 
begreppet: teknisk projektledare. 


3.2.3 Urval av företag och informanter 


Eftersträvanden som ansågs lämpliga var att informanterna skulle ha flera års erfarenhet inom 
IT-branschen och en gedigen meritlista. Denna kunskapsbas skulle också kombineras med att 
informanten haft en yrkesroll som teknisk projektledare under en längre tid. Företagen där 
informanten arbetar skulle vara inom den privata sektorn och verka inom Malmö- och 
Lundområdet. 


För en bättre överblick av de informanter vi intervjuade samt beskrivning av deras respektive 
företag se tabell 3.2. 
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Tabell 3.2 Redovisning av informanternas bakgrund och företag 


Företag 


Informanter 


A - Mindre IT-företag som är verksamma inom 
Lund. De är specialiserade på ett mindre 
segment av IT marknaden. 


A1 - Informanten har en lång och gedigen 
erfarenhet inom IT-branschen. Har under flera år 
jobbat som teknisk projektledare. 


B - Är ett större Svenskt produktionsföretag. 
Deras IT avdelning är lokaliserad i Lund. 


B1 - Är en rutinerad projektledare som varit 
verksam inom flera olika. 


C — Är ett större IT företag, med mycket 
verksamhet i Skåne. 


C1 — Mångårig utvecklare som även axlat rollen 
som projektledare under sin långa karriär. 


D —- Mindre IT-konsult företag verksamma inom 
öresundsregionen. 


D1 — Erfaren utvecklare som nyligen börjat utöva 
den tekniska projektledarrollen. 


3.3 Analys och bearbetning av data 


Enligt Holme & Solvang (1997) och Bryman (2008) råder det brist på väletablerade tekniker 
och metoder för att analysera data från kvalitativa undersökningar. Den analysmetod som 
studien eftersträvat syftar till att underlätta arbetet för forskarna, men även underlätta för 
läsarna att tolka det empiriska materialet. Metoden utgår ifrån Jacobsen (2002) teorier om hur 
kvalitativ data ska hanteras. De steg som är involverade är 


1. Beskrivning 
2. Systematisering och kategorisering 
3. Kombination 


Det är dessa steg vi arbetade efter i hanteringen av den empiriska datan, hur metoden 
tillämpades i vår studie förklaras i följande sektioner. 


Beskrivningen av den insamlade empirin (transkriberingen) har noteringar när informanten 


utför en konstpaus, eller när de är tveksamma till ett svar och funderar verbalt (Jacobsen, 
2002). Detta resulterade ofta i uttryck som: ”eehhh”. I syfte att förbättra transkriberingens 
läsbarhet begränsade vi involveringen av dessa verbala funderingar, bortsätt när de låg som 


grund för den vidare analysen. 


Den mängd data som erhålls från empirin är för omfattande för att en läsare ska kunna tolka 
dess innehåll, dess koppling till teorin och undersökningsmodellen. För att kunna visa den 


data som är av intresse för studien har vi använt oss av systematisering och kategorisering. Vi 


har haft detta i åtanke när vi utformat den struktur som analysen fått med början i sektion 


3.2.1 och sedan vidare i delkapitel 4.1. 


När den empiriska undersökningens data har strukturerats i kategorier och systematiserats 
återstår en del av analysen. Det är att använda och kombinera den kategoriserade datan i ett 
syfte. Enligt Jacobsen (2002) gäller det nu att leta efter meningar, orsaker samt att försöka 
generalisera och få ordning på den data som är av nytta för studien. I studien kommer detta 
utföras för att stödja den forskningsfråga vi har. Vi ämnar att samtidigt som vi påvisar de 


23 


Teknisk kompetens hos tekniska projektledare i mjukvaruutvecklingsprojekt Alm & Carlioth 


samband svaren genererar också återge en kort förklaring till varför vissa samband inte 
utkristalliseras lika tydligt. De tre delarna av den kvalitativa analysen kan beskrivas följa ett 
spiralliknande mönster, vilket illustreras närmare i figur 3.2. 


Rapport 


Kombinera 
Kategorisera 
Beskriva 


Data 


Figur 3.2 visar en typisk kvalitativ analysprocess 
(modifierad efter Dey, 1993 enligt Jacobsen, 2002, s. 217) 


Figur 3.2 visar den analysmetod studien använt sig av och kan med fördel förklaras med ett 
citat: 


”Vad vi ska försöka åstadkomma när vi använder en kvalitativ metod är att inte utelämna 
information som kan vara relevant. För att förhindra ett sådant utelämnande är det en 
strävan att hålla analysen så öppen som möjligt i inledningen, för att därefter gradvis snäva 
in informationen” (Dey, 1993 enligt Jacobsen, 2002, s. 217) 


3.4 Generaliserbarhet och kvalitet 


I den kvalitativa studien vi genomfört försäkrar vi oss efter olika reliabilitets och 
valideringsprinciper (delkapitel 3.2). Dock är det inte självklart att informanternas svar på 
intervjufrågorna är det svar som alla tekniska projektledare inom utvecklingsbranschen skulle 
lämna. Denna sanning som i vetenskapliga termer kallas intersubjektivitet innebär att flera 
personer är ense om att något är riktigt. För att inte undgå att uppnå intersubjektivitet har 
denna studie eftersträvat en strukturerad form. (Jacobsen, 2002) Enligt oss har det varit näst 
intill omöjligt för informanterna att tolka våra frågor olika, vilket bidrar till likartade svar. Vi 
är väl medvetna om att informanternas svar inte medger att utomstående personer hade svarat 
likartat. Detta och vidare brister i studiens metod redovisas för i nedanstående delkapitel. 


Delkapitlet fortsätter med hur vi strävat efter att kvalitetssäkra studien. Därefter följer tre 
sektioner som berör etik, reliabilitet och validitet. Dessa förtydligar hur vi valt att hantera det 
empiriska materialet samt hur vi strävat efter att uppnå en validerad studie. 
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3.4.1 Kvalitetssäkring 


Under arbetet med studien har aspekten om kvalitet uppmärksammats vid åtskilliga tillfällen. 
En bra uppsats skall kontinuerligt, genom studien, sträva efter att förefalla sig som ett 
argument. Det innebär att det problem som studien försöker utreda ska ha ett distinkt fokus. 
Avsaknaden av inhemska undersökningar har varit en av drivkrafterna att fullfölja den 
problemställning denna studie har. (Reinecker & Jörgensen, 2008) 


3.4.2 Etik 


Holme & Solvang (1997) samt Bryman & Bell (2005) argumenterar för att forskning som 
involverar människor som studieobjekt oftast innebär etiska problem. Nedan följer några 
punkter som ger mening till denna argumentation och som vi i denna studie strävat efter. 


Forskningspraxis 

Det finns ett tydligare hänsynstagande i de kvalitativa undersökningsmetoderna. Den 
maktutövning som befinner sig i dessa metoder är inte lika utpräglad som de kvantitativa är 
eftersom informanten kan ha en mer aktiv roll. Viktigt att beakta är att inte göra informanten 
till medel för sina egna mål. (Bryman & Bell, 2005) Denna aspekt blev extra viktig i denna 
studie eftersom vi valt en strukturerad ansats för den empiriska undersökningen. Vi lyckades 
ändå undvika att styra våra informanter i vår egna önskade riktning genom ett trevligt 
bemötande och en lämplig användning av intervjuteknik (sektion 3.3.3). (Andersson, 1994) 


Fysisk och psykisk integritet 

Förhållningssättet mot informanternas integritet ämnar till att skydda informationen 
informanten har bidragit med till forskningen. Vad det innebär är att varken tala om vilka 
företagen eller informanterna är, denna policy ska följas i och utanför studiearbetet. (Holme & 
Solvang, 1997) Detta har varit en grundläggande företeelse i den studie vi genomfört. 
Samtliga informanter har delgetts information att de kommer erhålla fullständig anonymitet. 
Vi har uppnått detta genom att referera till informanterna i transkriberingen som exempelvis 
Al1. Företagen erhåller också anonymitet. En aspekt som vi tagit hänsyn till som vi påstår är 
lätt att glömma är att hålla informanternas föregående anställningar anonyma. Därmed är det 
inte möjligt att spåra vilket företag intervjun är genomförd på genom att spåra informanternas 
karriär. (Holme & Solvang, 1997) 


Tystnadsplikt 

Det är viktigt att vara varsam med den fysiska integriteten efter att ha publicerat studien. 
Viktigt är dock att inte glömma bort tystnadsplikten vars etiska kontrakt startar dagen då 
beslutet om att intervjun ska genomföras. Riskerna är betydligt större att någon av misstag 
lyssnar sig till vilka företag som ingår i studien än att de av misstag får tillgång till det i läsbar 
form. (Holme & Solvang, 1997) De medel vi använt för att motverka denna risk är att 
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genomföra alla intervjuer på avskilda platser som inte utgör någon risk. All transkribering har 
skett under strukturerade former på isolerade platser med hjälpmedel som inte oavsiktligt 
avslöjar intervjuernas innehåll. 


Lurendrejeri/vilseledande 

De villkor som informanterna deltar på ska vara validerade villkor som inte förändras efter 
informanternas deltagande. Vad som menas med det är att informanterna ska veta i vilket 
syfte de deltar i undersökningen. Denna aspekt motverkar vi genom att delge samtliga 
informanter både den kompletta transkriberingen samt innan publicering också hela studien. 
(Holme & Solvang, 1997) En annan form av vilseledning är att forskarna påstår att arbetet 
handlar om något annat än vad det egentligen gör Bryman (2008). Detta har inte varit fallet i 
denna studie då samtliga informanter blivit informerade om vad studien tar upp och dess 
syfte. 


Rätten att ångra sig 

Denna punkt är en vidareutveckling av hur Holme & Solvang (1997) beskriver det etiska 
sättet att hantera den information informanterna delgivit. Om vi fått informanterna att lämna 
ut sig själva eller på något annat sätt enligt dem lämnat känslig information, anser vi att de har 
rätten att återkalla informationen. Enligt överenskommelse mellan oss och informanterna ska 
detta ske i god tid efter att de fått tillgång till informationen de lämnat. Om vi som forskare 
har rätten att utnyttja informanterna anser vi att de bör ha makten över själva 
informationshanteringen. 


3.4.3 Reliabilitet 


Om informationen som erhållits från en kvalitativ ansats inte håller tillräckligt hög reliabilitet 
kommer inte studiens frågeställning kunna besvaras på ett tillfredställande sätt. Reliabilitet 
handlar företrädesvis om huruvida resultaten av en studies mätningar är konsekventa eller ej. 
Det förekommer tre avgörande betydelser för reliabilitet och dessa kommer presenteras 
nedan. (Bryman, 2008); (Bryman & Bell, 2005) 


Stabilitet 

Det finns ett sätt att mäta om undersökningsmetoden är stabil i sin utformning. Enligt Bryman 
(2008) kan därför test-retest metoden appliceras. Den utgår ifrån att vid två olika tillfällen 
utföra samma undersökning. Avsaknaden av informanternas tillgängliga tid gjorde det 
omöjligt för oss att genomföra detta test på någon informant från själva undersökningen. Vi 
hade därför en förstudie (sektion 3.3.3) där denna metod tillämpades. Resultatet var 
tillfredställande och medförde att ett internt godkännande av undersökningen gjordes. 
(Bryman, 2008); (Bryman & Bell, 2005) 
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Intern reliabilitet 

Denna betydelse får innebörd när det förekommer flera forskare vid själva intervjutillfället. 
Risken är då att forskarna inte relaterar till samma sak i de svar som informanterna ger och 
saknar samstämmighet över hur svaren ska analyseras. För att förhindra detta att bli en realitet 
fördes djupa diskussioner angående vad intervjuns frågor syftade till och vilket resultat vi 
ville ha. Vi betraktar oss eniga i de studier som genomförts och anser därför att intern 
reliabilitet uppvidhålls i studien. (Bryman, 2008) 


Interbedömarreliabilitet 

Denna betydelse gäller i större utsträckning kvantitativa undersökningar. Betydelsen blir dock 
intressant när data ifrån en undersökning ska kategoriseras och det samtidigt finns flera 
forskare inblandade. Då finns risken att forskarna inte är samstämmiga i själva tolkningen av 
hur exempelvis en informant svarade eller reagerade på en specifik fråga. (Bryman & Bell, 
2005) Det vi gjorde för att undvika detta problem var att diskutera de svar som informanterna 
lämnat samt att skapa en strukturerad kategorisering av frågorna som faciliterade analysen av 
empirin. Internbedömarreliabilitet anpassades särskilt under arbetet som genererade den 
kategoriserade datan i delkapitel 3.7 och delkapitel 4.1. 


3.4.4 Validitet 


Att informationen från den kvalitativa undersökningen är reliabel är en förutsättning för att 
kunna få stöd i frågeställningen. Men utan att säkerställa att informationen som erhålls är 
validerad kan det inte säkerställas att mätningen kommer utföras på de premisserna som var 
utgångspunkten för forskningsfrågan. Samtidigt som det säkerställer informationens validitet. 
Detta är inte ett lika stort problem i kvalitativa studier som det är i kvantitativa studier på 
grund av att oklarheter kan redogöras vid själva intervjun. Ett problem som kvarstår vid 
kvalitativa studier är informanternas tolkning av intervjufrågorna. Det finns en tendens att 
informanten svarar på ett sätt som han eller hon tror är användbart för forskarna. (Holme & 
Solvang, 1997) 


Det tillvägagångssättet vi haft för att säkerställa validiteten av studien är att på förhand 
definiera vilka risker intervjufrågorna omfattade. En metod vi använt oss av var att i förväg 
definiera breda och svårtolkade begrepp, detta för att ingen tvekan skulle infinna sig på 
begreppets mening. På det sättet säkerställer vi att informanterna inte svarar utifrån en 
definition de själva har när frågan ställs. Denna aspekt kombineras också med 
förhållningssättet att inte lägga svaren i informanternas mun vilket annars kan generera ett 
svar som är påverkat. Vidare har svaren från intervjuerna granskats av oss båda ur ett kritiskt 
perspektiv, då analysen av empirin inte skall vara baserad på felaktigheter. Slutligen har 
informanterna från intervjutillfället varit medvetna om att de ska få granska transkriberingen 
av intervjuerna. Alla informanter har godkänt och inte haft några invändningar på 
transkriberingen av sin respektive intervju. 
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3.4.5 Kritik av metoden 


Enligt Jacobsen (2002) möts forskare i valet av en kvalitativ ansats utmaningen när det gäller 
att behålla den externa giltigheten. Jacobsen (2002) fortsätter med att beskriva att kvalitativa 
ansatser ofta har svårigheter med att de resultat som en studie visar inte motsvarar hur ett 
fenomen egentligen förhåller sig. 


Den forskningsstrategi vi har valt är således beroende av att tillförlitliga svar ges från de 
informanter som ingår i den empiriska undersökningen. I denna studie har det lagts mycket 
kraft på att säkerställa att informanterna dels befinner sig i en teknisk projektledarposition 
samt har den erfarenheten som kräver tillförlitliga svar. Den kritik som är värd att lyfta fram 
med den kvalitativa undersökningsmetoden är dess strukturerade natur. Holme & Solvang 
(1997) argumenterar för skillnaderna mellan kvalitativa och kvantitativa undersökningar där 
den förstnämnda kretsar kring flexibilitet och den andra efter struktur. 


Den största kritiken vi kan ge denna studies metod var att dess kvalitativa 
undersökningsmetod var strikt strukturerad. Frågorna som intervjuguiden bestod av var på 
förhand definierade och även dess följdfrågor var fördefinierade. Risken med detta 
angreppssätt var att det kan få en sorts inlåsningseffekt och den naturliga flexibiliteten 
kvalitativa undersökningsmetoder är känd för gås om miste. Därmed blir det inte en rik studie 
(Jacobsen, 2002) 


Ytterligare kritik kan ges mot sättet som den analyserade data presenteras. Den presenteras 
strukturerat med hjälp av tabeller och följer en etablerad analysmetod som är anpassad för 
kvalitativa studier. Det som dock saknas är att data inte visualiseras på ett sätt som gör att 
läsaren omedelbart förstår resultatets innebörd. Vi ser inte att vi har tillräcklig kvantitet från 
vår analys för att kunna göra en sådan statistisk mätning. Istället har fokus lagts mot att 
koppla informanternas åsikter mot undersökningsmodell vi använt oss av (delkapitel 2.4). 
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4 Redovisning av empiri 


Vi kommer i detta kapitel redovisa de empiriska fynden som gjorts på ett strukturerat sätt med 
hjälp av en tydlig kategorisering av intervjufrågorna (tabell 3.1). Våra informanters bakgrund 
och deras företag tydliggörs i tabell 3.2. Vi har valt att delat upp de olika intervjufrågorna i tre 
huvudkategorier. Redovisningen av intervjufrågorna görs med en summerande text, följt av en 
tabell med resultatet från frågan. Även figurer förekommer för att förenkla fynd vi gjort. 


4.1 Projektledning 


4.1.1 Tidigare projektledningserfarenheter (Ämne 1.1) 


Den första frågan i projektledningskategorin visar tydligt på att informanternas tidigare 
erfarenheter var väldigt spridda. De hade allt från flerårig erfarenhet, inom både teknisk 
projektledning men även administrativ projektledning, till informanter som nyligen tagit ut sin 
magisterexamen från systemvetenskapliga institutionen i Lund. (tabell 4.1) 


Tabell 4.1 Tidigare projektlednings erfarenheter 


Informant | Ståndpunkt Nr. i transskript 
A1 10 års erfarenhet av projektledning. Inom utveckling, men även 11-14 
innehavt rollen som kravställare 
B1 Besatt de kunskaper som en magister examen i systemvetenskap | 9-10 
innebär 
C1 Viss tidigare erfarenheter av projektledning innan det nuvarande 17-18 
jobbet 
D1 Nämner inte några tidigare erfarenheter 13-14 


4.1.2 Vilken fas av projektets livscykel är de tekniska kunskaperna av störst 
vikt/betydelse? (Ämne 1.2) 


På frågan om var i projektets livscykel som teknisk kunskap är av störst betydelse var 
samtliga av informanterna överens om att det var i början av projektet som det var viktigt, då 
främst under förstudien samt förarbetet. Vidare var även en majoritet överens om att teknisk 
kunskap har betydelse i genomförandefasen. Värt att notera var även att ingen ansåg att behov 
av teknisk kompetens behövdes i slutet av livscykeln (tabell 4.2). För en visuell bild av 
informanternas svar se figur 4.1. 
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A1 B1  Förarbete C€1 D1 
Genomförande 
Efterarbete 


eidé 
eförstudie 


edefinition 


estart 


eanalys LS | Öd 
eutformning B1 C1 
ekonstruktion 2 TN 
RT 


eproduktionsättning A1 C1 
eöverlämning — N 


eavslutning A1 


eavveckling 


eerfarenhetsinsamling 


Figur 4.1 Sammanställning av informanternas svar i tabell 4.2 
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Tabell 4.2 Vilken fas av projektets livscykel de tekniska kunskaperna är av störst vikt/betydelse? 


Informant | Stånadpunkt Nr. i transskript 
A1 Förarbete, test samt överlämning. 15-18 
B1 Genomförande med analys och utformning. Till viss del förarbetet 11-14 
också. 
C1 Under förstudierna, med analys, utformning, konstruktion och test. 23-24 
D1 Viktigt i början, i förstudie samt förarbetet. 15-20 
4.1.3 Genomgått någon form av projektledningsutbildning i tjänsten? (Ämne 1.3) 


Tre av fyra informanter hade genomgått någon sorts utbildning inom projektledning. Det var 
skilda områden de fick lära sig inom projektledning. En informant lärde sig hur projekt leds 
och planeras, samtidigt som en annan fick lära sig om projektledningsverktyg. Samtliga 


informanter var dock överens om att den projektledningsutbildning de hade fått varit 
användbar i deras roll som teknisk projektledare. (tabell 4.3) 
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Tabell 4.3 Genomgått någon form av projektledningsutbildning i tjänsten? 


Informant | Utbildning? | Förstärkt kunskap inom vilket Har utbildningen Nr. i transskript 
område”? varit användbar? 

A1 Ja Integrering av utspridda Ja 25-30 
utvecklings team 

B1 Ja Ledning och planering Saknas 17-20 

C1 Ja Projektverktyg samt jobba med Absolut 25-32 
teambuilding 

D1 Nej 22 


4.1.4 Avsaknad av några specifika projektledaregenskaper i syfte att höja sin 
kompetens som teknisk projektledare? (Ämne 1.4) 


Den sista frågan ur projektledningskategorin berör avsaknad av kompetenser för informanten. 
Återigen var det väldigt skilda svar från informanterna. En deltagare väljer att inte svarar på 
frågan utan börjar prata om annat. En vill bli bättre på struktur samtidigt som en annan vill 
kunna förstå utvecklingsmetoder bättre. Det är vitt skilda kompetenser som nämns. (tabell 
4.4) 


Tabell 4.4 Avsaknad av några specifika projektledaregenskaper i syfte att höja sin kompetens som 
teknisk projektledare? 


Informant | Ståndpunkt Nr. i transskript 
A1 Se och lyfta fram nyckelpersoner 31-32 

B1 Utökad förståelse kring metoder, ex. Scrum 23-26 

C1 Nämner inga 

D1 Att bli bättre på att få struktur och planera sitt arbete 23-24 


4.2 Mjukvaruutveckling 


4.2.1 Vilken teknisk kompetens är relevant för en teknisk projektledare? (Ämne 
2.1) 


Den första frågan ur kategorin mjukvaruutveckling berörde vilka kompetenser som är relevant 
för en teknisk projektledare. Samtliga personer som intervjuades nämnde att kunskap om 
utveckling är en viktig kompetens att ha med sig. Det nämndes även att den tekniska 
projektledaren inte behöver vara någon utmärkt utvecklare själv, utan att det är viktigt att ha 
förståelsen för utvecklingens olika svårigheter. Utöver utveckling nämns även 
testkompetenser samt utvecklingsmetoder som viktiga. (tabell 4.5) 
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Tabell 4.5 Vilken teknisk kompetens är relevant för en teknisk projektledare? 


Informant | Ståndpunkt Nr. i transskript 

A1 Fokus på att ha en bra systemöversikt, kunna de 33-34 
systemutvecklingsverktyg som finns, samt duktig på tidsstyrning. 

B1 Viktigt att förstår den utvecklingsmetod som används i sitt projekt 21-28 


samt utvecklat själv.. Exempel på tekniker som en teknisk 
projektledare bör förstå: TDD(Test-driven development), 
MVC (Model view controll) 


C1 Programmering och test 43-44 


D1 Alla delar är viktiga, men oftast är det utvecklarrollen som har mest | 25-28 
kompetenser. Utvecklare behöver ofta testa samt installera servrar. 
Det är inte säkert att en driftperson eller testare någonsin skriver 
kod. Detta gäller specifikt i ett utvecklingsprojekt. 


4.2.2 Bör tekniska projektledare ha erfarenhet av: programmering, test, drift och 
support samt eftermarknad? (Ämne 2.2) 


Majoritet av våra informanter bedömer att en teknisk projektledare bör ha erfarenhet av rollen 
som programmerare. De motiverar detta med att den tekniska projektledaren måste förstå 
programmerarna, hur de tänker, vilka problem de kan stöta på. Dock nämner de att nackdelen 
med att den tekniska projektledaren har tidigare programmeringserfarenheter kan leda till att 
denne gärna själv sätter sig och programmerar. Hälften av informanterna tyckte att den 
tekniska projektledaren borde ha erfarenheter som testare. Dock framhävde dem att det inte 
var det viktigaste, utan snarare ett komplement då programmeringsrollen idag ofta inkluderar 
testning. Det var bara en av våra informanter som uttalat sa att det var bra med erfarenhet av 
drift- och supportrollen. Dock ansåg de övriga informanterna att det var en bra merit. Ingen 
påstod uttryckligen att eftermarknad var en bra erfarenhet. Dock ansåg informant A1 att det 
kunde vara en nyttig erfarenhet. (tabell 4.6) För en bra överblick hur våra informanter svarade 
på frågan i tabell 4.6, se figur 4.2. 
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Tabell 4.6 Bör teknisk projektledare ha erfarenhet av följande roller? 


Alm & Carlioth 


Informa | Programmerare Testare Drift/Support Eftermarknad” Nr. i 
nt transskript 
A1 Ja, för att ha Samma Alltid lika bra med | Nyttigt med 35-52 
förståelse. anledning som erfarenheten, erfarenheten att 
Avsaknad av programmerare. | men inte lika se hur kunden 
detta kan leda till | För att ha känt viktigt som tar emot 
en dålig av den programmering systemet, men 
projektledare. frustration som och test. det är ingen 
Nackdel är att kan infinnas superkritisk 
projektledaren som testare. erfarenhet. 
har svårt att hålla | Inga nackdelar. 
fingrarna borta 
från 
programmeringen 
B1 Absolut, du får en | Nej, inte lika Nyttig erfarenhet, | Ser 29-40 
förståelse för de viktigt som inte ett krav. eftermarknaden 
arbetena som programmerare. | Oftast finns en som drift och 
dina utvecklare Idag har ofta utvecklingsorgani | support. Främst 
utför. Du kan programmerarn | sation och en drift | pga. Tidigare 
kommunicera a ett visst test organisation. erfarenheter. 
med dem, samt tänk. Dock har Bredare 
förstår deras rena testare mer | erfarenhetsbas 
problem. Nackdel | kunskap kring projektledaren har 
du programmerar | test, men jag desto bättre. 
själv. tror inte det är 
lika viktigt. 
C1 Nej, inte den Nej, inte Ej tillämpbart. Nej, inte viktigt. | 53-62 
viktigaste viktigaste 
kunskapen. egenskapen. 
D1 Ha förståelse En bra Ja, bra Inte viktigt för 29-44 
över hur lång tid erfarenhet. erfarenhet. Inte tekniska 
samt vad som Kunna olika det viktigaste. projektledare de 
går att utveckla metoder, samt Finns skall vara 
är viktigt. Nackdel | beroende på standardiserat fördefinierade. 
styr gärna projekt är test som man hänger 
utvecklingen lite viktigare än på projektet. 
för mycket. utveckling. 
Nackdelar låter 
testarna testa 
efter egen 
förmåga. 


> Den efterföljande marknad som infinner sig efter försäljning samt leverans av produkt eller tjänst 
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Programmerare 


Testare 


Drift och support 


Eftermarknad 


Figur 4.2 Sammanställning av informanternas svar i tabell 4.6 


4.2.3 Hur förhåller sig en teknisk projektledare i kommunikationen med beställare 
och utvecklare? (Ämne 2.3) 


Denna sista fråga i mjukvaruutvecklingskategorin utröner hur förhållningen av 
kommunikation mot utvecklare och beställare fortlöper, ur en teknisk projektledares 
synvinkel. Svaren från informanterna var i denna fråga splittrade. Hälften av svaren benämner 
kommunikationen mot utvecklarna som fortlöpande och daglig, samtidigt som 
kommunikationen mot beställarna sker färre antal gånger, men är då mer strukturerad. De ser 
även sin roll som teknisk projektledare som en tolk mellan utvecklare och beställare. Den 
andra hälften av informanterna nämner istället att tolkrollen har försvunnit till följd av de 
agila utvecklingsmetoderna. Nu sker kommunikationen mer och mer mellan utvecklare och 
beställare. (tabell 4.7) 


34 


Teknisk kompetens hos tekniska projektledare i mjukvaruutvecklingsprojekt Alm & Carlioth 


Tabell 4.7 Hur är förhållningen av kommunikationen mot beställare samt utvecklare? 


Informant | Stånapunkt Nr. i transskript 


A1 Gäller att prata olika språk. Mot utvecklarna på ett sätt och mot 53-60 
kund på ett annat. Kommunikationen mot utvecklarna är dock 
kontinuerlig samtidigt som kommunikationen mot beställare är mer 
transgent. Detta innebär att man måste få ut mer och 
förberedelserna är därför större inför möte med kund, medans 
möten med utvecklarna är mer iterativa och sker ofta. 


B1 Ingen stor skillnad idag. Beror på att utvecklarna börjar arbeta enligt | 41-42 
metoder som också inkluderar beställaren i en process, ex. Scrum. 
Tidigare när vattenfallsmodellen användes var det två olika språk 
mellan utvecklare och beställare. Då gjorde man kravställning, och 
efter det diskuterades det tekniska och sedan fick du se vad som 
producerats efter 6 månader. Idag är det högre krav på utvecklare 
att förstå affärsspråk. Systemvetenskap har ju tidigare beskrivits 
som Översättare mellan affären och tekniken men det handlar inte 
om det längre, man översätter inte man pratar redan samma språk. 
Det handlar om att facilitera processen inte att prata olika språk 
utan att det man pratar om blir gjort på ett bra sätt. 


C1 Kommunikationen med utvecklarna är lite tätare, daglig basis, 63-68 
ständig kommunikation. Men mot beställare är det mindre frekvent, 
men ändå tight. Tendenser är att det är mer agila metoder kontra 
den gamla vattenfallsmodellen. 


D1 Viktigt att kunna agera som ett filter mellan utvecklarna och 45-46 
beställarna. Det är två olika språk. Ofta handlar det om att lyfta 
beställarnas önskemål och krav, förstå dem och sedan 
kommunicera detta på ett vettigt sätt ner till utvecklarna, så även de 
förstår. 


4.3 Kompetens 
4.3.1 Erfarenhet av att jobba som utvecklare? (Ämne 3.1) 


Första frågan i kategorin kompetens är en tvådelad fråga som först utröner huruvida 
informanten har jobbat som utvecklare, samt om denne anser det viktigt med yrkesmässig 
kompetens för att lyckas i rollen som teknisk projektledare. Samtliga av informanterna har 
tidigare arbetat som utvecklare. Svaren vi får är väldigt identiska från samtliga deltagare i 
intervjun. De var alla överens om att det var viktigt, men de poängterar samtidigt att det inte 
var den viktigaste kompetensen. Hälften av informanterna lyfter istället fram förmågan att 
kommunicera och verbalt uttrycka sig så alla i projektet förstår. (tabell 4.8) 
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Tabell 4.3 Erfarenhet av att jobba som utvecklare? 


Alm & Carlioth 


Informant 


Jobbat som 
utvecklare? 


Viktigt med yrkesmässig kompetens som utvecklare 
för att lyckas som teknisk projektledare? 


Nr. i transskript 


A1 


Ja 


Nej, man behöver inte, men väldigt bra att ha. En 
god kommunikationsförmåga kan överväga, ex. att 
omsätta väldigt abstrakta krav och egenskaper till 
något som utvecklingsteamet förstår eller att 
visualisera komplexa förhållanden som man måste 
ha förståelse för när man utvecklar. 


61-66 


B1 


Ja 


Om det är utvecklingsprojekt så är det viktigt. Dock 
står utveckling bara för 20-3096 av industriell IT. Om 
du jobbar utanför utveckling så är det istället 
kravställning, uppföljning och mätning som är viktiga 
egenskaper. 


43-46 


C1 


Ja 


Nej, det är viktigt men inte det viktigaste. Viktigare 
att vara duktig verbalt och förstår hur organisationen 
fungerar och att du kan prata för dig och ditt projekt. 
Behöver man tyngre teknisk kompetens har man 
folk som kan hjälpa en med det. 


69-76 


D1 


Ja 


Det är viktigt, men framgång kan ändå nås. 
Fördelen är att man förstår vad hela kodningen 
innebär. Erfarenhet av utvecklingsprojekt är viktigt, 
att bara gå in och försöka leda utan erfarenhet kan 
leda till så många misstag som kanske aldrig gjorts 
om erfarenheterna funnits. 


47-52 


4.3.2 


Vilka kompetenser är viktigast för att kunna bedriva ett tekniskt projekt? 


(Ämne 3.2) 


Frågan kring vilka kompetenser som är viktigast för att kunna bedriva ett tekniskt projekt kan 
enklast utläsas ur figur 4.3. Poängsystemet i figuren utgår från hur informanterna svarat med 
fem poäng för den viktigaste och ett poäng för den minst viktiga kompetensen. Här ser vi 
tydligt att det är mjukvarukvalitet samt utvecklingsmetodik som informanterna bedömer som 
viktigast. Tätt därefter följer mjukvaruarkitektur. De två kompetenser som informanterna 
ansåg vara av minst vikt var djup programmeringskunskap samt kunskaper om människa- 
dator interaktion (HC). (tabell 4.9) 
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Tabell 4.9 Vilka kompetenser är viktigast för att kunna bedriva ett tekniskt projekt? 


Informant | Stånapunkt Nr. i transskript 


A1 1 Mjukvarukvalitet 67-68 
2 Utvecklingsmetodik 

3 Mjukvaruarkitektur 

4 Djup programmeringskunskap (slåss med plats 3, beror på 
storleken på projektet i fråga) 

5 Kunskaper om människa dator interaktion 


B1 1 Utvecklingsmetodik (Projektledaren ansvarar för metoden, se till 47-54 
att den fungerar, och att du förstår den) 

2 Mjukvaruarkitektur(Viktigt med arkitektur idag, lyckas man med 
sin utvecklingsmetodik samt arkitekturen har man bra 
förutsättningar att lyckas med sitt projekt) 

3 Mjukvarukvalitet (Skall värnas om, och bakas helst in i metoden) 
4 Kunskaper om människa dator interaktion (Förstår inte 
användarna skapar det inget värde) 

5 Djup programmeringskunskap Det är vad dina utvecklare skall 
vara bra på. Har du för djupa kunskaper inom programmering så är 
risken att endera att du engagerar dig i utveckling, det är inte ditt 
uppdrag. Eller nummer två att du försöker påverka utvecklingen, 
inskränker utvecklarnas frihet genom att försöka berätta i detalj vad 
dem ska göra och det är kontraproduktivt) 


C1 1 Utvecklingsmetodik (Här ligger de mjuka värdena som är viktiga 77-82 
för att kunna navigera sitt team rätt) 

2 Mjukvarukvalitet 

3 Kunskaper om människa dator interaktion 
4 Mjukvaruarkitektur 

5 Djup programmeringskunskap 


D1 1 Mjukvaruarkitektur 53-56 
2 Mjukvarukvalitet 

3 Djup programmeringskunskap 

4 Utvecklingsmetodik 

5 Kunskaper om människa dator interaktion 
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Figur 4.3 Sammanställning av resultatet ur tabell 4.9 
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4.3.3 Någon kompetens som vidare kan utvecklas för att bli en bättre teknisk 
projektledare? (Ämne 3.3) 


Den sista frågan i kompetenskategorin berör frågan om någon kompetens kan vidareutvecklas 
för att bli en bättre teknisk projektledare. Hälften av informanterna framhåller förmågan att 
istället för fördjupning av sin kunskap inom ett specifikt område, bredda sin kunskapsbas. 
Informant B1 (tabell 4.10) diskuterar ingående vikten av att se hela kedjan i projektet, 
samtidigt som D1 diskuterar vikten av att ha bred kunskapsbas som medför förståelse för 
projektets tekniker. Samtliga informanter berör i sitt svar kompetenser som förbättrar eller 
förenklar för projektteamet. (tabell 4.10) 


Tabell 4.10 Kompetens som kan vidare utvecklas för att bli en bättre teknisk projektledare? 


Informant | Stånadpunkt Nr. i transskript 

A1 Förmågan att snabbt förstå och få en intuitiv uppfattning om hur ett | 69-74 
komplext system fungerar. Detta för att hjälpa ett utvecklingsteam. 

B1 Övergripande projektplanering. Att förstå hela kedjan av ett projekt. | 55-56 


Teknisk projektledare del kanske sträcker sig 6 månader, medans 
projektet i helhet sträcker sig i två år. Desto bättre förståelse för 
projektet som helhet desto bättre. Oftast är det utomstående 
faktorer som påverkar ditt team negativt, att då ha bra kontroll över 
vad som händer är viktigt. 


C1 Argumentation, samt att bli bättre på att sälja sitt projekt så fler får 83-86 
upp ögonen för produkten vi levererar. 
D1 Bredda sin kunskapsbas, och se till att inte gå på djupet. Utan att 57-58 


sträva efter att få in hela projektets tekniker, så man förstår 
innebörden av det. 
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5 Diskussion 


Vi kommer i detta avsnitt djupare diskutera resultaten i våra empiriska intervjuer. Kapitlet 
inleds med att påståendena och frågorna beskrivs. Därefter ges hänvisningar till var 
påståendena och frågorna behandlas i undersökningsmodellen (tabell 2.1 & tabell 2.2). Sedan 
kopplas påståenden och frågorna mot både teorin samt empirin. Detta för att se om 
påståendena och frågorna överensstämmer med den empiriska data vi fått fram. Slutligen förs 
en diskussion angående utkomsten av denna jämförelse. Denna process upprepas under varje 
sektion med början på sektion 5.1.1. 


5.1 Redovisning av påståenden ur undersökningsmodellen 


I detta delkapitel redogörs alla påståenden som presenterades i tabell 2.1. 


5.1.1 Påstående om tekniska projektledares tekniska kompetens 


Det första påståendet handlar om att teknisk kompetens behövs för att kunna verka i rollen 
som teknisk projektledare. Med det första påståendet hävdar vi med stöd från litteraturen, att 
tekniska kompetenser behövs för att kunna verka i rollen som teknisk projektledare (tabell 
2.1). Påståendet grundar sig i två av studiens teoriområden, teknisk projektledning samt 
faktisk kompetens och stödjer sig på teorier som presenteras i sektion 2.1.3 & sektion 2.3.3. I 
tabell 4.5 visar tre fjärdedelar av intervjudeltagarna att det är viktigt för tekniska projektledare 
att ha en viss erfarenhet av utveckling för att kunna leda tekniska projektarbeten. Vidare visar 
hälften av empirin rörande den tekniska projektledaren att de behöver förstå metoderna som är 
relevanta för dennes förmåga att leda arbetet (tabell 4.5). Metoderna kännetecknas som 
utvecklingsmetoder (sektion 2.2.2) samt utvecklingsverktyg. 


Intervjusvaren ger ett förhållandevis tydligt svar på att tekniska projektledare behöver teknisk 
kompetens för att kunna leda tekniska projekt. Svaren kommer från olika företag som 
befinner sig i olika branschinriktningar med förhållandevis olika syn på teknisk 
projektledning. Med denna grund blir detta påstående verifierat av empirin. Vi kan hålla med 
det svar empirin ger oss när det kommer till att både kunskaper inom utveckling och 
utvecklingsmetodik är viktiga. Det är också viktigt att de tekniska projektledarna ska kunna 
kommunicera med utvecklarna om problem de har. 


Projektledaren ska även kunna applicera exempelvis utvecklingsmetoder som underlättar 
utvecklarnas arbete. Kunskap inom de systemutvecklingsverktyg som används av utvecklarna 
inte är lika relevant för en teknisk projektledare (tabell 4.5). Vi tycker inte det är relevant att 
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en teknisk projektledare lägger ner tid på att uppdatera kunskaperna inom företagets 
systemutvecklingsverktyg. Det är mer relevant för en teknisk projektledare att styra 
utvecklarna med hjälp av olika metoder som dessa med enkelhet kan applicera med stöd av 
systemutvecklingsverktyg. En av informanterna hade en intressant tankegång angående varför 
de tekniska projektledarna inte ska vara för mycket involverade i utvecklingen eller med 
systemutvecklingsverktygen. 


”[...|Det största problemet om du själv är programmerare och framförallt om du tycker det 
är kul så tenderar du att bli mer en utvecklare än en teknisk projektledare. Du engagerar dig i 
projektet och när projektet stöter på problem med tid och leverans och någonting sådant så 
är risken ganska stor att du själv sätter dig ner och programmerar då. Det är inte huvudsyftet 
då för dig som teknisk projektledare.” (tabell B2.2, rad 34). 


Vi kan hålla med om åsikten hur betydelsefull den tekniska projektledarens involvering i 
utvecklingen samtidigt som vi tror att denna aspekt är applicerbar på långt fler exempel än på 
de vi presenterar i denna studie. 


5.1.2 Påstående om projektledningsutbildning 


Nästa påstående berör huruvida projektledningsutbildning behövs för att stärka den formella 
kompetensen hos tekniska projektledare. Efter genomförd utbildning kan efterfrågad 
kompetens ha uppnåtts. I den teoretiska genomgången behandlas inte 
projektledningsutbildningar i detalj på grund av att vi då hade frångått vår inriktning mot de 
tekniska kompetenserna hos tekniska projektledare. Vi ansåg ändå att det hade varit intressant 
att utreda om informanterna stödjer sig mot några projektledningsutbildningar och om dessa 
har hjälpt dem i rollen som tekniska projektledare. Vi ansåg det också intressant att utreda om 
de efter denna utbildning erhållit en mer efterfrågad kompetens, detta presenteras i tabell 2.1. 
Trots avsaknaden av teoriavsnitt som koncentrerar sig kring projektledningsutbildning 
hänvisade vi mot den projektledningsutbildning som är tillgänglig i form av certifiering (PMI, 
IPMA) som berörs i inledningen samt i undersökningsmetoden. 


I tabell 4.3 visar den empiriska undersökningen ett resultat som inte involverade den sorts 
projektledningsutbildning vi förväntade oss en teknisk projektledare skulle ha genomgått. 
Majoriteten av informanterna hade någon gång genomgått utbildning inom 
projektledningsområdet. Uteslutande fokuserar dessa utbildningar på att förbättra de mjuka 
projektledningsegenskaperna såsom ledning och hantering av arbetsteam. Dessa utbildningar 
visade sig dock till större del vara användbara i informanternas fortsatta roller som tekniska 
projektledare. Därmed är påstående två verifierat av empirin. Till att börja med ges inga 
tecken från empirin att teknisk projektledningsutbildning behövs för att de tekniska 
projektledarna ska erhålla mer efterfrågad kompetens. Även om utbildningarna inte var 
ämnade att förbättra informanternas tekniska projektledningsförmåga visade utbildningen sig 
ändå vara användbar. 
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Det empiriska resultatet visar att mer formell kompetens i projektledning inte nödvändigtvis 
gör någon till en bättre teknisk projektledare vilket är något vi kan instämma i. Vi tycker även 
att erhållen utbildning i ledning och hantering av arbetsteam borde vara en självklarhet för en 
teknisk projektledare. 


5.1.3 Påstående angående ledarskap och teknik 


Detta påstående handlar om tekniska projektledares förmåga att kunna kombinera tekniska 
kunskaper med egenskaper att kunna leda och hantera arbetsteam. Sektion 2.3.3 tar upp 
teorier om vilka de viktigaste egenskaperna en teknisk projektledare ska ha som ämnar stödja 
honom eller henne i sitt uppgiftsutövande. I påstående ett berörde vi frågan om hur viktiga de 
tekniska kunskaperna är för en teknisk projektledare. Men enligt teorierna i sektion 2.3.3 
återstår ett antal kunskapsområden att bemästra. 


Vidare vill vi nu utreda vilka svar den empiriska undersökningen kan bidra med. Det är värt 
att nämna att de tekniska projektledarnas egenskaper av teamledning generellt 
uppmärksammats i informanternas svar. Nästan alla informanter lyfter tydligt fram betydelsen 
av en teknisk projektledares egenskaper att kunna guida sitt team mot ett gemensamt mål utan 
att nödvändigtvis behöva tillämpa tekniska lösningar. Lika relevant för ledning av 
utvecklingsteamet är den tekniska projektledarens mjuka ledaregenskaper, som att vara en 
sympatiskt och karismatisk ledare. Själva ledningen av teamet består också av att kunna 
översätta de verksamhetsregler som antingen organisationen eller kunden sätter (tabell B2.1, 
rad 66). Detta ställer krav på att den tekniska projektledaren har kunskaper i verksamhetens 
funktioner för att kunna styra utvecklingsteamet för att uppnå det målet. Vidare uttrycker sig 
en informant att den tekniska projektledaren inte är i lika stort behov av ledarskapsförmågor 
som administrativa projektledare. Enligt informanterna behöver den tekniska projektledaren 
snarare koncentrera sig på metoden utvecklarna ska arbeta efter istället för kunskaper inom 
gruppdynamik och sociala förmågor (tabell B2.2, rad 26). 


Detta svar är intressant eftersom det är en åsikt angående inom vilket ledningsområde de 
tekniska projektledarna ska verka. Förmodligen kommer utvecklingsteamets utformning rent 
arbetskraftsmässigt förändras efterhand. Det innebär att det vid ett flertal tillfällen kan uppstå 
kommunikationskonflikter inom teamet, dessa kan underlättas med en utarbetad arbetsmetod. 
Försummas den tekniska projektledarens ledarskapsansvar kan detta resultera i att den 
tekniska projektledaren är oförberedd på att hantera sitt team om det uppstår en konflikt. 


5.1.4 Påstående om projektets livcykel 


Sista påståendet berör var i projektets livscykel de tekniska kunskaperna är av störst vikt 
varierar från projekt till projekt och från en branschinriktning till en annan. Det sista 
påståendet hävdar att den tekniska kompetensen är viktig under olika delar av projektets 
livscykel och för olika företag i olika branscher (tabell 2.1). Till att börja med är det viktigt att 
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beakta förekomsten av olika livscykelteorier (sektion 2.1.1) eftersom det inte finns någon 
etablerad standard för ett projekts livscykel. Det är snarare så att det finns många olika 
livscykelteorier anpassade för olika ändamål. Att det inte finns någon standardisering kring 
livscykelteorier är anledningen som får oss att uppmärksamma individernas kompetens i 
projekten. Det kan säkerligen finnas undantag då företag kan ha specifika livscykler de 
använder sig av och som nyrekryterade får utbilda sig inom. Eftersom de resurser företaget 
har är utbildade för att anpassa en sorts livscykelteori följer inte tekniska projektledare efter 
någon etablerad livscykelstandard. 


Den livscykelteori vi använt under den empiriska undersökningen var begriplig för 
informanterna eftersom samtliga informanter med lätthet kunde relatera till 
livscykelmodellen. Detta resultat presenteras i tabell 4.2. Samtliga informanter var också 
eniga om att de tekniska kunskaperna var viktiga i projektets förarbete. Hälften av 
informanterna ansåg det viktigt med de tekniska kunskaperna under analys- och 
utformningsfasen. Bortsett från dessa faser i projektets livscykel var det några andra som fick 
en del uppmärksamhet vilket går att urskilja i figur 4.1. 


Svaret den empiriska undersökningen gett oss stödjer inte det påstående vi från början 
formulerat. Även om informanterna kommer från helt olika företag och befinner sig i olika 
branscher är svaren förhållandevis lika. Samtliga informanter är överens om att de tekniska 
kunskaperna är viktiga i förarbetet. Flera informanter är även överens om att den tekniska 
kompetensen är fordrad i ett flertal av genomförandefasens underfaser (figur 4.1). De 
skillnader som dock uppstår beror med allra största säkerhet på informanternas bakgrund och 
branschinriktning. Förmodligen har en någorlunda praxis utformats för det tekniska 
kompetensbehovet i valda delar av projektets livscykel. 


5.2 Redovisning av frågor från undersökningsmodellen 


I detta delkapitel redogörs alla frågor som presenterades i tabell 2.2. 


5.2.1 Fråga om tidigare tekniska erfarenheter 


Den första frågan berör vilka tidigare tekniska erfarenheter behöver en teknisk projektledare? 
I denna fråga (tabell 2.2) undrar vi vilka tekniska erfarenheter en teknisk projektledare 
behöver. För att besvara denna fråga hänvisar vi till vår empiri. I tabell 4.6 går vi grundligt 
igenom varje fråga från frågeställningen vi gjort i vår undersökningsmodell. Det vi fann i vår 
empiri var att en majoritet av informanterna ansåg att samtliga nämnda områdena var av 
intresse, dock i olika stor utsträckning. Den erfarenhet som var av störst värde var 
programmeringserfarenheten. Programmeringsrollen angränsar ofta till flera andra roller så 
som test och drift/support, dvs. har personen erfarenhet från programmering har denne med 
stor sannolikhet också erfarenhet från de andra områdena. (tabell B2.4, rad 26) Detta var en 
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av de huvudsakliga anledningarna till att programmeringsrollen var viktig. En annan 
anledning var att majoriteten av ett utvecklingsprojekt består av programmerare. Har den 
tekniska projektledaren då erfarenhet av utveckling kan han hjälpa och förstå en majoritet av 
sin grupp. Vi samtycker med empirin. Det faktum att all tidigare erfarenhet, den tekniska 
projektledaren tar med sig in i ett projekt är av värde, tillsammans med förståelsen av att 
programmering är av största dignitet då det tillför mest värde. Det som förvånar oss i empirin 
är det svala intresset för tidigare erfarenhet av eftermarknad. Vi anser att det beror på att de 
tekniska projektledarna inte behöver handskas med eftermarknaden lika frekvent, utan 
leveransen mot eftermarknaden är vanligtvis skött av en annan avdelning. 


5.2.2 Fråga om kommunikationsegenskaper 


Nästa fråga (tabell 2.2) behandlar hur kommunikationen sker från en teknisk projektledares 
synvinkel mot beställaren samt utvecklaren. Vår empiri (tabell 4.7) är splittrad i denna fråga. 
Informanterna är överens om att det sker mer kommunikation mot utvecklarna än mot 
beställarna, men kommunikationen är mer strukturerad mot beställarna. De är dock inte ense 
om hur själva kommunikationen sker mellan beställare, utvecklare och tekniska projektledare. 
Hälften hävdar att den tekniska projektledaren agerar mer som en tolk mellan beställarna och 
utvecklarna, samtidigt som den andra hälften förespråkar att det skett en förändring kring den 
tekniska projektledarens roll och har därav förändrat hur de kommunicerar. Denna förändring 
innebär att tolkrollen successivt har fasats ut till följd av nya utvecklingsmetoder som gör att 
utvecklarna istället blir involverade i kommunikationen mot beställarna. En av informanterna 
hävdar att det numera är mindre skillnad på kommunikationen mot beställare samt mot 
utvecklare: 


”[...] Det beror på att man börjar arbeta enligt metoder som också inkluderar beställaren. 
Beställaren kallar vi kanske idag för produktägaren inom Scrum, den är en del av en process. 
Tidigare arbetade man enligt vattenfallsmodellen, då pratar man två helt olika språk” (tabell 
B2.2, rad 42). 


Vi tycker det är intressant att notera, efter våra intervjuer, att de som gått över till en agil 
utveckling också är de som anser att kommunikationen har förändrats. De som fortfarande 
jobbar med vattenfallsmetoden är de som tycker den tekniska projektledaren agerar tolk 
mellan beställare och utvecklare. Beroende på vilken utvecklingsmetod som utnyttjas ställs 
olika krav på kommunikationen för den tekniska projektledaren. En intressant aspekt av 
frågan var också kravet som ställdes på utvecklarna som jobbar med agil utveckling. Att även 
de måste ha en bättre affärsförståelse idag för att kunna kommunicera med beställare. 
Eftersom då fler och fler företag börjar applicera agila metoder, att detta ställer andra krav på 
den tekniska projektledaren, och dess roll troligen kommer att förändras. Deras roll som tolk 
kommer successivt försvinna samtidigt som kraven på utvecklarna kommer öka. 
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5.2.3 Fråga om den viktigaste tekniska kompetensen 


Den tredje frågan handlar om vilka av följande kompetenser anses vara viktigast hos en 
teknisk projektledare: Mjukvaruarkitektur, Djup programmeringskunskap, Goda kunskaper 
om utvecklingsmetodik, Kunskaper inom människa-dator interaktion och Mjukvarukvalitet? 
Denna fråga (tabell 2.2) var en rangordningsfråga där vi undersökte vilka kompetenser som 
var av störst vikt för att kunna bedriva ett tekniskt projekt. Det resultat vi fick fram ur empirin 
(tabell 4.9) var en enhetlig syn om vad som var viktigast. Tydlig överblick av svaren kan ses i 
figur 4.2. Det är påtagligt att både utvecklingsmetodik samt mjukvarukvalitet var de två 
kompetenserna som var viktigast. De kompetenser som ansågs vara av minst värde var 
kunskap om människa-data interaktion samt djup programmeringskunskap. Informanterna 
formulerar den tekniska projektledarens roll, mer som en guide, än teknisk rådgivare i 
projekten. Detta resonemang stödjs då utvecklingsmetodik var av störst vikt, och 
utvecklingsmetodiken som guidar utvecklarna i projektet från början till slut. Har den tekniska 
projektledaren goda kunskaper i utvecklingsmetodik kan han lättare hjälpa utvecklarna. Vi ser 
motiveringen till att mjukvarukvalitet var så pass viktig med att den tekniska projektledaren 
har det övergripande ansvaret för produkten som levereras, det är därför hans ansvar att 
kvalitet upprätthålls. 


5.2.4 Fråga om avsaknaden av kompetens 


Sista frågan handlar om vilka kompetenser saknas ofta hos en teknisk projektledare, samt 
vilka kompetenser behöver de generellt förbättra? Den sista frågan vi vill få svar på (tabell 
2.2) ställer sig frågande till vilka sorts kunskaper en teknisk projektledare känner att denne 
saknar, samt vill förbättra. Empirin påvisar vitt skilda egenskaper i frågan om avsaknad 
kompetens (tabell 4.4). Det var allt från en ökad förståelse för utvecklingsmetoder till att 
kunna strukturera och planera sitt arbete effektivare. Denna fråga var väldigt bred och det kan 
vara en av anledningarna till att vi fått skilda svar. Den slutsats som kan dras är att det inte 
finns någon gemensam kompetens som informanterna känner att de saknar. 


De svar vi fick avseende vilka kompetenser som de tekniska projektledarna känner att de 
skulle kunna förbättra (tabell 4.10) är mer enhetlig. Även om svaren inte är identiska kan ett 
mönster utläsas ur svaren. Det är generalistegenskaperna som framhävs istället för 
specialistegenskaperna. De nämns explicit i en intervju: 


”[...] Det är alltid det här med att bredda sin kunskapsbas, och inte gå djupare för det har 
man ofta ingenting för, men just att försöka bli bredare” (tabell B2.4, rad 58). 


En annan informant diskuterar förmågan att få en komplett överblick över projektet i sin 
helhet. Detta för att få en förståelse över hela projektet och lättare kunna identifiera potentiella 
fallgropar och rätta sig därefter. Vi tror empirin stämmer då den tekniska projektledaren i sin 
roll inte längre har behov av djupa kunskaper, utan snarare breda kunskaper för att kunna 
hjälpa till och lyfta alla delar i projektet. 
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6 Slutsats 


I uppsatsen har vi svarat på vår forskningsfråga: 
Hur betydelsefull är den tekniska kompetensen hos tekniska projektledare inom 
mjukvaruutvecklingsprojekt? 


Undersökningsmodellen påvisar hur forskningsfrågan genom de tre teoretiska områdena leder 
fram till en kategorisering i fyra frågor och fyra påståenden. Dessa behandlas sedan i 
diskussionen tillsammans med resultatet från den empiriska undersökningen. Vidare klarläggs 
diskussionsområden som både ligger som grund för svaret på forskningsfrågan men som även 
lyfter fram andra diskussionsområden. Dessa kan beskrivas som endast stödjande mot 
forskningsfrågan men betraktas ändå enligt oss som väsentliga att presentera och gör även så i 
delkapitel 6.1. 


Det svar som studien genererat efter ovanstående process är enligt följande: 
Den tekniska kompetensen är betydelsefull, men inte avgörande för att den tekniska 
projektledaren ska kunna axla denna roll. 


De tekniska kompetenserna kännetecknas i denna studie av den tekniska projektledarens 
programmerings- och testkunskaper samt kunskaper inom drift och support. Studiens resultat 
visar på att det framförallt är programmeringskunskaperna som är viktiga medan 
testkunskaperna är något mindre viktiga. En teknisk projektledares kunskaper inom drift och 
support är minst viktiga enligt studiens resultat. 


Att dessa tekniska kompetenser är betydelsefulla betyder att tekniska projektledare med hjälp 
av dem kan mer effektivt bedriva tekniskt präglade dialoger med utvecklare. Det innebär att 
den tekniska projektledaren då kan förstå utvecklarnas problem. Därefter kan de tekniska 
projektledarna applicera en arbetsmetod som är anpassad mot utvecklarnas behov. Att de inte 
är avgörande för att axla denna roll kan förtydligas med att det fortfarande finns många 
projektledare med stort tekniskt ansvar som inte har en särskilt utpräglad teknisk kompetens. 
Ofta ställs då höga krav på att dessa projektledare har påtagliga planerings- och 
kommunikationskunskaper. 


De faktorer som avgör om någon är redo att axla rollen teknisk projektledare beror på ett 
flertal olka förhållanden. Ett förhållande kan vara rent företags- och branschspecifik, hur 
organisationen ser på ledarskap bestämmer kraven på den tekniska projektledarens tekniska 
kompetensnivå. Om en organisation traditionellt sett låtit utvecklare axla rollen som tekniska 
projektledare kan trenden luta mot att de tekniska projektledarna ska en tydlig teknisk 
kompetens. Studien framhäver ytterligare en faktor vilket är om personen i fråga kan 
kommunicera tillräckligt bra med sina utvecklare. Detta innebär att personen måste ha 
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grundläggande förståelse för främst programmering som enligt studien bäst erhålls från att 
utveckla själv. 


Under insamlingen av empirin och utformningen av analysen blev det uppenbart att vår studie 
berörde fler områden än de som var direkt riktade mot vår forskningsfråga. Det var för oss 
bekant att utveckling kan genomföras på ett traditionellt sätt med en begynnande 
kravställning, likt den så kallade Vattenfallsmetoden. Fler och fler organisationer har dock 
börjat tillämpa agila utvecklingsmetoder, exempelvis Scrum. Dessa berörde vi i uppsatsens 
litteraturgenomgång (sektion 2.2.2). Dock lade vi inte fokus på vad dessa utvecklingsmetoder 
begärde för kompetenser av en teknisk projektledare. 


Svaret på fråga två i delkapitel 5.1 lyfter fram den nyss nämnda aspekten i mer detalj. En 
teknisk projektledare har under en längre tid betraktats som en tolk mellan beställare och 
utvecklare. Krav har alltid ställts på att de tekniska projektledarna ska kunna prata båda dessa 
språk. Med större tillämpning av de agila metoderna blir beställarna mer och mer involverade 
i processen för själva produktutvecklingen. Beställarna får ideligen uppdateringar på hur 
arbetet fortlöper och får därför bättre förmågor att tala det tekniska språket som tidigare en 
teknisk projektledare hade översatt för dem. 


Det vi nu föreslår till vidare forskning är hur rollen teknisk projektledare kommer påverkas av 
detta skifte i att arbeta. En trend visar på att de forna tekniska projektledarna söker ett 
tydligare ansvar för själva utvecklingsmetoden. Frågan är om detta får dem att frångå en roll 
som projektledare för att istället anta en roll som mer liknar den metodansvarige i Scrum 
(Scrum master). Intressant är också att utreda om detta är en återkommande trend oavsett om 
företagen arbetar med nyutveckling eller förvaltning av IT. Slutligen är den sammanfattade 
frågan vi ställer för vidare forskning enligt följande: 


Kommer den traditionella rollen teknisk projektledare förändras i samband med ytterligare 
tillämpning av agila utvecklingsmetodiker? 


6.1 Begränsningar 


Arbetet med denna studie har varit en otrolig lärdom som vi tidigare inte erfarit. Något som 
enligt oss kännetecknar nya erfarenheter är att lärdomarna intas efter fel som görs vilka sedan 
rättas till. Denna studie har präglats av ett fåtal motgångar, vissa av dessa hade vi gjort 
annorlunda om chansen gavs. 


Studiens största begränsning anser vi är kombination av lite för få informanter kombinerat 
med att dessa informanter möjligtvis tenderar att ha mer utvecklingserfarenhet än 
projektledningserfarenhet. Den naturliga följden av detta är att informanterna framförallt 
förespråkar de tekniska kompetenserna. Förvisso demonstrerar resultatet att framförallt 
programmeringskunskaperna är viktiga för en teknisk projektledare. Vi anser dock att det 
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huvudsakliga resultatet inte påverkats eftersom resultatet visar att de tekniska kunskaperna är 
betydelsefull men inte avgörande. 


Ytterligare en begränsning studien har är att de tekniska kompetenserna inte involverar 
kompetens inom hårdvara eller IT-säkerhet. Det är förstås tekniska kompetenser som är 
viktiga för en teknisk projektledare. Vi förutsätter ändå att resultatet inte har avvikit avsevärt 
utan att ha involverat dessa kompetensområden. 
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Bilagor: 


B1 Intervjuguide 


Bakgrund: 
För att få en mer övergripande bild över informanterna samt en djupare förståelse för dess 
tekniska bakgrund ställer vi följande frågor: 


1. Vad är din titel idag? 
2. Vilka tekniskt" inriktade arbetsuppgifter har du? 
3. Kan ni beskriva kortfattat vad ni har för tidigare jobberfarenheter inom IT-branschen? 
3.1 Av de jobb som ni haft, vilken har haft mest betydelse för den rollen ni har 
idag? 


Projektledning: 

4. Vilka projektledningserfarenheter hade du (om några) innan du fick jobbet som 
teknisk projektledare? 

5. Under vilken fas av projektets livscykel" anser ni att era tekniska kunskaper är av 
störst vikt/betydelse? 

6. Har ni genomgått någon projektledningsutbildning under ert yrkesverksamma liv? 
Ja- Vilka kunskapsområden syftade den att förstärka er inom? 

Har ni haft användning för utbildningen? 


Nej — Se nästa fråga. 


7. Finns det några projektledaregenskaper ni saknar för att kunna bli en mer kompetent 
tekniska projektledare? 


Teknik: 
8. Vilken teknisk" kompetens anser du relevant för en teknisk projektledare? 


Varje påstående leder till en följdfråga i form av Ja eller Nej, för att få ett uttömmande svar 
från intervju objektet på varje teknisk punkt. 
9. Anser du att en teknisk projektledare bör ha tidigare erfarenheter av följande roller: 


Programmerare, Testare, Drift och Support, Eftermarknad”"> 


Ja- Vad ser du för fördelar med det? Finns det några nackdelar? 
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Nej- Varför inte? 


10. Hur förhåller sig kommunikationen mellan er som teknisk projektledare mot 
beställare" "> samt utvecklare? 


Kompetens: 


11. Har ni under er karriär arbetat som utvecklare? 
11.1 Anser ni att det är viktigt att ha en yrkesmässig kompetens inom utveckling för 
att lyckas i rollen som teknisk projektledare? 


Ja — Vilket sorts utveckling? 
Nej — Vad anser ni då har mer betydelse? 


12. Vilka av följande tekniska kompetenser anser ni vara mest betydelsefullt för att kunna 
bedriva ett tekniskt projekt. Rangordna kompetenser nedan med det ni tycker är 
viktigast först. 

e Myjukvaruarkitektur 

e - Djup programmeringskunskap 

e Goda kunskaper inom utvecklingsmetodik(Agila osv.) 
e Kunskaper inom människa dator interaktion 

e Myjukvarukvalitet(Test) 


13. Finns det någon kompetens ni anser kan utvecklas vidare i strävan att bli än ännu 
bättre teknisk projektledare 


"Teknisk kompetens: Programmering, test, drift/server 

"> Visa livscykelmodell för att minimera risken av missförstånd ang vilken modell vi menar 
">+Eftermarknad: När produkten är levererad och anses vara färdig, den efterföljande tiden. 
x+X>+Beställare: De personer som beställt systemet, ofta de som finansierar projektet. 
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B2 Transkriberingar av intervjuer 


Tabell B2.1 Intervju med A1 (2011-04-18) 


1. Erik: Då ska vi börja med några bakgrundsfrågor. Detta för att mest för att få 
en övergripande bild över vem du är. Du är min första fråga Vad är din 
titel idag. 

2. Al: Vad är min titel? Civilingenjör, då kan man aldrig bli en före detta. 

3. Erik: Har du någon alternativ titel? 

4. AN: I och med att det är ett litet företag där så finns det inga formella titlar. Det 


är mer om man hyrs in som konsult, som projektledare eller sub 
projektledare. Men då är det en dynamisk titel, för det man gör vid den 
tidpunkten. Titelmässigt så är där inget kopplat som vid stora företag där 
man måste veta var man är någonstans i organisationen och vilka 
skyldigheter man har. 


5. Erik: Vi går raskt in på nästa fråga. Vilka tekniskt inriktade arbetsuppgifter har 
du och med tekniskt menar vi programmering, test och drift/ support. 


6. Al: Det där är egentligen från ax till limpa. Det vill säga allt ifrån systemdesign 
till identifiering av kundbehov, upp till drift och förvaltning/ underhåll av 
system. Det är en väldigt bred bit i och med att du jobbar mot en 
organisation. Som har totalansvar. 


Zan SEK: Ja det är bra, tack! 
Då går vi till nästa fråga. Kan ni kortfattat beskriva vilka tidigare jobb 
erfarenheter ni har från IT-branschen innan det positionen ni har idag? 


8. Al: Det man då kan säga är att den är väldigt lång. Den är fokuserad mot 
kommunikation och säkerhet, för att fatta sig kort, så har den rört sig från i 
princip 80 talet, alltså mot kommunikation och säkerhet. Var det svar på 
frågan? 

9 Erik: Ja det var det! 

Det kommer faktiskt en följdfråga på detta, så du kommer få utveckla 
detta lite. Följdfrågan lyder, av de jobb ni haft, vilken har haft mest 
betydelse för de jobb ni har idag? Anser ni själv? 


10. A1: Det har nog varit, säkerhetsuppdragen i och med att de har blivit mer och 
mer viktiga från att ha varit något katten släpade in från början av 
internets historia till nu är livsavgörande, säg den inriktningen då. 


11. Erik: Tack, då avslutar det bakgrundsfrågorna och vi går in på frågorna kring 
projektledning. 

Då lyder första frågan såhär: Vilka projektledningserfarenheter hade du 
om du haft några, innan du fick jobbet som teknisk projektledare, om man 
nu kan kalla din titel för det. 

12. A1: Nu ska vi tänka här, ja det var utvecklingssidan, viss mån, men inte 
speciellt mycket i alla fall va. För egentligen vid min roll där som 
representant där som kund, som gjorde stora beställningar, i detta fall 
beställningar för försvaret, där man var med som kravställare och 
godkännandet och test av stora system. Typ radar station. 

13. Erik: Om jag ställer en följdfråga på den, skulle du kunna uppskatta hur många 
år som du haft denna projektlednings erfarenhet. 
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14. 


155 


23. 


24. 


25. 


26. 


21. 


28. 


29. 


30. 


A1: 


Erik: 


Erik: 


A1: 


Erik: 


A1: 


Erik: 


A1: 


Erik: 


A1: 


Säg 10 år, innan man tog de stora egna projekten. 


Tack, då går vi till den första och enda bild frågan. Du kommer få se en 
bild efter jag ställt frågan. Under vilken fas av projektets livscykel anser ni 
att de tekniska kunskaperna är av störst vikt eller betydelse. 


Det var singularis, det var vilken? 
Ja precis, men du får gärna nämna fler än en. 


Det är förarbete, och test, överlämning, där ligger det. 

Så egentligen under hela förarbetet och under nästa fast från test till 
genomförandet. 

Ja så kan man säga. 


Ja, ok! 

Det är lite black box när man väl beslutats vad som skall göras definierat 
och skrivit ner specarna så är det black box vad som händer. Oftast när 
man skriver systemspecarna så tänker man ofta hur testar jag det här. 
Det är typiskt att man följer upp de testerna som nu skall utföras eller vad 
det nu är för någonting. Den test fas som tas vid. 


Bra! 


Blev det nu som vi ville ha det.. typ. Samtidigt anser jag då att den 
viktigaste att bygger man fel från början så ligger man helt fel på det hela 
tiden, därför är det en väldigt viktig del, den här ide fasen , från fantasi till 
vad kommer hända nu. Hur styr vi upp det, hur mäter vi de här resultaten 
som vi vill ha. Går det att mäta så man lägger tid i början av projektet. Så 
man inte kastar sig in hals över huvud i projektet och kodar. Och speciellt 
nu när kodning till viss mån handlar om att outsourca. Väl strukturerat 
förarbete gör att du kan vara relativt oberoende fri från vem du tar in för 
att utföra kodningen. Vilket kan vara en fördel om man vill hyra in kodare 
från andra länder. Då gäller det att man är väldigt strukturerad i ide fasen 
och struktur fasen och kan test och till och med låta genomförarna själv 
testa. De ska veta redan vad de skall testa på så de bitarna är de ja 
fokuserar på. 


Tack så mycket! 
Vi fortsätter med nästa fråga. Har ni genomgått någon projektlednings 
utbildning under er yrkesverksamma liv? 


Intressant, har man fått det? Det var väl inom Ericsson, jag jobbade en 
del som konsult inom Ericsson, i huvudsak mot Kanada. Det var en 
internutbildning. Det var inte någon allmän projektlednings utbildning utan 
snarare hur driver vi projekt på Eriksson. 


Vilka kunskapsområden syftade den att förstärka er inom? 


Där var det integration av olika utvecklings team. Spridda i olika länder 
och olika kulturer. Jag kan berätta att utvecklingsteamet i Irland inte hade 
samma uppfattning om Maniana Manian som de som satt i Mexica. Det 
blev lixom lite kultur skillnader där kan man säga. Just det hur får man 
utspridda projektutvecklings grupper att samverka. Och det var innan det 
var utpräglat att ha intranät osv inom företagen. Då var det telefon och fax 
som gällde. 


Har ni haft användning för denna utbildningen, I den senare delen i er 
yrkesverksamma liv? 
: Jaaa, det har man väl haft, men utvecklingen går så fort. Man brukar 
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säga att vishet är det man kommer ihåg när man glömt allt det man lärt 
sig, och det är ungefär där jag ligger, jag kommer inte ihåg något men jag 
är säkert vis av erfarenhet. 


ST SENK? Då går vi till den sista projektledningsfrågan. Den lyder såhär: Finns det 
några projektledningsegenskaper som ni saknar för att bli en mer 
kompetent teknisk projektledare? 

32. A1: Det är inte lätt att vara ödmjuk när man vet att man är bäst! Men, absolut 
finns det. Att kunna lyfta fram människor som jobbar i organisationen och 
som har tekniska idéer, och att det verkligen lyfts fram, och kommer 
projektet till godo. Det är viktigt att ge rätt form av delegering, lönar sig att 
hålla fingrarna borta. Där hade jag kunnat bli bättre. Det är i alla fall 
påtagligt att när man jobbar i en vältrimmad organisation så ser man 
dörrarna stå öppna och man skriver ut när man har problem respektive 
när man har dörrarna stängda och så märker man inte problemet förens 
man gör integrations tester att man har problem. Det kostar enormt 
mycket mer om man upptäcker det då. Så det flödet kan man jobbar 
mycket på, utbyte av information och utan att det blir brus som det finns 
risk att det kan bli. Där skulle man kunna bli bättre. Det var det som var 
frågan? 

33. Erik: Ja precis. Tack så mycket. 

Nu går vi raskt vidare, och vi går in på den näst sista kategorin och då 
lyder frågan, vilken teknisk kompetens anser du relevant för en teknisk 
projektledare, och nu pratar vi om teknisk kompetens som 
programmerare, testare samt server/drift. 

34. A1: Alltså teknisk projektledare tycker jag alltså skall ligga relativt högt upp i 
systemet men inte vara rädd för att gå ner. Han skall ha god förståelse för 
de problem och egenskaper som det har, men samtidigt hålla sig över 
vattenytan, och se till helheten, så man inte sub-optimerar någonting i 
utvecklingsfasen. Fokuserar för mycket kapacitet på några delar. Så 
systemutvecklings verktyg kunna dem, kunna följa upp. Mycket 
tidsstyrning, även om man pratar om teknisk projektledare så ramlar det 
ändå ner till att man skall avgöra vad timmarna skall gå till och hålla reda 
på det. Så jag tycker man skall ha god förståelse och hålla sig undan låg 
nivån och vara bättre på systemöversikt som teknisk projektledare. Segla 
skutan om man säger så. 

35 ENik: Ja vi förstår. Tack så mycket 


Då går vi vidare till nästa fråga. Det här är en liten formaliseringsfråga. 
Varje påstående leder till en följdfråga i form av ja eller nej 


Anser du att en teknisk projektledare bör ha tidigare erfarenheter av 
följande frågor: 
Att vara programmerare, ja eller nej? 


36. Al: Ja 
37. Erik: Vad ser du för fördelare med det? 
38. A1: Alltså förståelsen för bultarna och skruvarna och allting som ligger där 


nere. Alltså har man inte kört huvudet i väggen och insett på riktigt alltså 
mer än att gå utbildningen mer än att kunna det även mer än att ha 
praktiserat det. Man behöver inte ha gjort mycket så länge man har 
ödmjukheten inför det, om man inte har det så tror jag att man blir en 
dålig projektledare. 


DÖ ENK: Finns det några nackdelar med att man sysslat med det innan? 

40. A1: Jepp! Man kan ha svårigheter att hålla fingrarna ur syltburken. 

41. Erik: Vi går vidare till nästa påstående, testare ja eller nej. 

42. A1: Ja för att vara god programmerare så ska man ha egenskap av att vara 
testare också egentligen av samma anledning som föregående 
påstående. 

43. Erik: Även för en teknisk projektledare? 
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44. 


45. 


46. 


52. 


53. 


54. 
IS. 


56. 


57. 


58. 
59. 


60. 


A1: 


Erik: 


A1: 


A1: 


Erik: 


A1: 


=E 


A1: 


Erik: 


A1: 


ER 


A1: 


Ja även för en teknisk projektledare. Men återigen så behöver det inte 
vara... men det ska vara mer än praktik om man säger så. Man ska ju ha 
gjort det in real life och oftast så skriver man någras delar av systemet 
och så testar man någon annans del så att man känner hur frustrerad 
man kan vara som testare för det är en väldigt viktig egenskap eller viktig 
funktion. 

Ja det förstår jag. 


Kan du urskilja några nackdelar i det här också att man kan test som 
teknisk projektledare? 


Om det kan ha några nackdelar...naaaeee...inte så påtagligt som 
programmerare för det är nästan bättre som teknisk projektledare att man 
är med som testare och har förståelse där för det är där skiten ansamlas 
och då gäller det att snabbt kunna ta beslut. 

Då går vi ner till det näst sista påståendet, drift och support 

Eeeeh...det blir ju nästan så att allt blir viktigt. Men det är inte dumt att ha 
det. Men man kan säga att man har det ur praktiksynpunkt. Man har sett 
hur det kan vara från supportbiten men inte lika viktigt som det andra 
ändå. Så kan jag svara något så är det nej. 

Kan du motivera det med något ytterligare? 

(Längre tanke paus) Nej, det är bara en känsla 

Då går vi till sista påståendet, eftermarknad och då menar vi när 
produkten är levererad och anses vara färdig och den efterföljande tiden 
efteråt, anser du att en teknisk projektledare bör ha tidigare erfarenheter 
av det här området? 

Alltså marknads erfarenhet är alltid bra för att eftersom man möter 
kundens erfarenheter av system som är framtaget och har en förståelse 
för det är inte dumt alltså. Det är ungefär som systemtest alltså, jag skulle 
inte säga att det är superkritiskt. 

Nästa fråga kräver lite förklaring från min sida, men jag ställer frågan först 
och förklarar sen. 


Hur förhåller sig kommunikationen mellan er som teknisk projektledare 
mot beställare samt utvecklare? 

Beställare menar vi då de personer som beställt systemet och de som 
finansierar det i projektet och utvecklarna alltså programmerarna och 
testarna, de som implementerar det. 

Alltså vilket dilemma ställs man inför? 

Ja precis men specifikt hur kommunikationen fungerar för er mot de olika 
rollerna. 

Ja då gäller det ju att prata med den lärde på latin men även också prata 
med bönderna på deras språk. Med den kommunikationen ska man få 
fram vad är kundens behov och sedan kommunicera in det i teamet även 
om det här ska ha kondenserats ut i goda specifikationer innan, det ska ju 
finnas där. Den rollen, den var det frågan var va? Den rollen den tekniska 
projektledaren hade mellan de här två? 

Hur förhåller sig själva kommunikationen mellan er som tekniskt 
projektledare mot då beställare och utvecklare, alltså de som jobbar 
under er samt era kunder. 

Hur det förhåller sig? 

Hur sker kommunikationen, finns det något du kan utveckla från den 
sidan som är beställarna och den sidan som är utvecklarna? 

Man kan säga att kommunikationen mot utvecklarna är ju kontinuerlig och 
daglig men i alla fall på den nivå man driver ett team. Kommunikationen 
mot beställarna, den är ju mer transgent (transient?) det kommer 
fortlöpande möten någon gång i månaden, det beror på intensitet. Det 
gäller att informationsutbytet mot beställarna har en högre bandbredd om 
man kan säga så om ni förstår vad jag menar, mer information på kortare 
tid. Medan kommunikationen mot den tekniska personalen 


53 


Teknisk kompetens hos tekniska projektledare i mjukvaruutvecklingsprojekt Alm & Carlioth 


61. 


67. 


68. 


69. 


Erik: 


Erik: 


A1: 


Erik: 


A1: 
Erik: 
A1: 


programmerare och testare kan vara mer iterativ och kontinuerlig, så är 
det ju skillnad hur kommunikationen sker. Det innebär också som Winston 
Churchill sa ”Ska man ha ett långt tal så behöver man bara förbereda sig i 
fem till tio minuter, men ska man hålla ett kort tal så kanske man behöver 
förbereda sig i två dagar.” Likadant så förberedelser för att träffa kunden 
kan vara ganska omfattande men för att träffa personalen så är det mer 
fortlöpande. Så är det skillnad på dem två sätten att kommunicera. Så det 
är två olika egenskaper i att kommunicera. 

Nu går vi in på sista kategorin som hanterar kompetens. 

Då lyder frågan enligt följande: 

Har ni under er karriär arbetat som utvecklare, då menar jag som 
programmerare och testare 


Ja 

Anser ni att det är viktigt att ha en yrkesmässig kompetens inom 
utveckling för att lyckas i rollen som teknisk projektledare? 

Nej 

Vad anser ni då har mer betydelse än det här? 

Man behöver inte men det är väldigt bra att ha. Däremot finns det lysande 
undantag som man har sett som inte har det men som har en väldigt god 
kommunikationsförmåga. Att omsätta väldigt abstrakta krav och 
egenskaper till något som utvecklingsteamet förstår. Att visualisera 
komplexa förhållanden som man måste ha förståelse för när man 
utvecklar. Det kan vara väldigt goda egenskaper som ersätter allt annat. 
Nu fortsätter vi, 

Vilka av följande tekniska kompetenser anser ni vara mest betydelsefullt 
för att kunna bedriva ett tekniskt projekt? 


Nu kommer jag be er att rangordna kompetenser som jag kommer visa 
er, jag vill att ni börjar med den viktigaste. 

Du får läsa dem själv för att sen rangordna dem (Intervjuobjektet får se 
kompetenserna på datorskärmen) 

Sen kan du säga 1 följt av kompetensen och så vidare. 


Då ska vi se, det är nog, man ska nog säga att mjukvarukvalitet kommer 
först. 

Och sedan då olika kunskaper inom olika utvecklingsmetodiker. 

Sedan mjukvaruarkitektur, men det brås på i vilken omfattning för den 
slåss med djup programmeringskunskap. Det beror på storleken på 
projektet. 

Kunskaper inom människa dator interaktion kommer sist men det beror 
också på vilket sorts projekt man bedriver. 


Men det blir väl dem ordningarna där 
Så då var det en fråga kvar. 


Finns det någon kompetens ni anser att ni kan utveckla vidare för att bli 
en ännu bättre teknisk projektledare? 


Alltså generellt sätt? 

Alltså nej egentligen hos er? 

Det kan vara komplexitets seenden, att snabbt förstå och få en intuitiv 
uppfattning om hur ett komplext system fungerar. Det kan man träna sig i 
då, det är alltid det som begränsar, beroende på om man kör några agila 
metoder eller spiralutveckling. 

Att man väldigt enkelt och överskådligt snabbt kan övergå i vad som kan 
beskrivas som total brist på förståelse av hur ett system fungerar. 

Att kunna tänja lite på dem gränserna, hur man nu gör det är en 
egenskap. Den skulle jag gärna vilja utöka. Så att man hänger med lite 
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mer i den komplexitetsspiralen 


73. Erik: Hur ser du på det generellt sätt? 

74. AM: Frågan är om det inte är den här komplexitetsbilden, förmågan att förstå 
och korrekt analysera komplexa system alltså för att hjälpa ett 
utvecklingsteam. En projektledare ska ju bara hjälpa till som en 
stödfunktion, och kunna förmedla hur systemet ska fungera på riktigt. 

75. Erik: Det avrundar vår intervju, tack så jättemycket 

76. Al1: Varsågod. 
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Tabell B2.2 Intervju med B1 (2011-04-19) 


1. Erik: Första frågan blir då, vad är din titel idag? 

2. B1: Min titel är idag, manager competences and plattform, nej så är det 
inte. Manager plattform and web competence center, det är min titel 
idag. 

3. Erik: Nästa fråga lyder, vilka tekniska inriktade arbetsuppgifter har du nu? 
Med tekniskt menar vi programmering, testning och drift /support. 

4. -B1: Jag har ansvaret för utvecklingen och tester, integrationstester på 


.net plattformen. Jag jobbar inte själv aktivt med att programmera 
eller att testa, men jag ansvarar för metoden och personalen samt 


kompetensen. 

5. Erik: Och nästa fråga lyder, kan ni beskriva kortfattat vad ni har för tidigare 
erfarenheter inom IT-branschen? 

6. B1: Ja, jag har jobbat med it sedan 2001 och jag började som 


programmerare, under ett par år. Sedan var jag projektledare, 
tekniska projektledare under ett par år, affärsanalytiker, sedan var 
jag ansvarig för mjukvaruutveckling inom ett svenskt industribolag, 
sedan var jag projektledare för strategiska projekt här internt, och 
sedan fick jag mitt nuvarande jobb. 


7. Erik: Av de jobb som ni haft vilket har varit mest betydelsefull för den 
rollen ni har idag? 
8. B1: Jag skulle säga att den rollen jag har idag så är det alla erfarenheter 


tillsammans. Det är svårt att identifiera en, men skulle jag tänka mig 
in i vilken jag har mest erfarenhet och nytta av inom teknisk 
projektledning så skulle jag säga att det var utveckla. I alla fall när 
det gäller teknisk projektledning, men inte administrativ 
projektledning. 

9: Erik: Det avrundar bakgrundsfrågorna. Då går vi in på frågorna kring 
projektledning. Då lyder första frågan: Vilka 
projektledningserfarenheter om du hade några innan du fick jobbet 
som teknisk projektledare? 

10. B1: Mitt första jobb som teknisk projektledare fick jag efter att jag tagit 
min magisterexamen på systemvetenskapliga programmet på Lunds 
Universitet. Så de projektledningserfarenheterna jag hade har ni 
också skulle man kunna säga. 

11. Erik: Tar vi nästa fråga direkt. Under vilken fas under projektets livscykel 
anser ni att era tekniska kunskaper är av störst vikt eller betydelse. 
Vi visar nu en bild vilken livscykel vi använt oss av. 


Ser du? 

12. B1: Ja, Menar du nu, förarbete, genomförande, efterarbete eller menar 
du de mindre punkterna? 

13. Erik: Ja, om det är någon specifik punkt som du anser att det kan ligga 
mer tonvikt vid. 

14. B1: mm, som teknisk projektledare skulle jag säga att, egentligen i 


genomförandet, då skulle jag säga analys och utformning, om 
utformning är när man tänker design och arkitektur, om man har det i 
den betydelsen så är det där det är viktigast att ha 
utvecklarerfarenhet. Lite beroende på hur man definierar förarbete så 
skulle jag nog säga att det skulle vara viktigt där också Men allt som 
oftast i min värld, så förarbetet så pratar man inte så mycket system 
utan då pratar man behov, och problemställning. Genomförandet då 
går man över till lösning, och då pratar man system och arkitektur. 


15. Erik: Men som projektledare, även fast du är tekniskt inriktad då, är du 
ändå involverad i förstudien då, överhuvudtaget? 
16. B1: Ja, absolut, det behöver inte vara samma projektledare som kör 


förarbetet som kör genomförandet. Det skiljer sig inom olika 
organisationer. Hos oss är idé och förstudiedefinition hanteras allt 
som oftast av en annan del av organisationen, men när den går in i 
realisering så går den in i en annan del av organisationen. Det är 
pga. Fokus och till viss del kompetens kan man då säga. 
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17. Erik: Tack. Vi tar nästa fråga. Har ni genomgått någon projektlednings 
utbildning under ert yrkesverksamma liv? 

18. B1: Jajemen. 

19. Erik: Inom vilka kunskapsområden syftade den på att stärka er inom? 

20. B1: Främst inom ledningsbiten. Ledning och planering, skulle jag vilja 
säga. 

21. Erik: Ganska uteslutande. Det är inte mer social teambuilding förmågor? 

22. B1: Njaa. Allt som oftast projektledningsutbildningar, i alla fall på större 


svenska industriföretag där min erfarenhet baseras på där är det mer 
fokus på metoden och snarare än de sociala. De sociala och grupp 
dynamik det tenderar att mer finnas inom ledarskapsutbildningar och 
inte projektlednings utbildningar. 

23. Erik: Kan jag tänka mig. Sista frågan på projektledning: Finns det några 
projektledningsegenskaper ni saknar för att känna er som en mer 
kompetent projektledare? 


24. B1: Absolut. 

25. Erik: Finns det någon du kan peka på? Som du känner att du kanske hade 
kunnat utveckla ändå mer? 

26. B1: Mycket kring metoderna i dagens utveckling som jag inte behärskar. 


Som jag som teknisk projektledare vilja kunna mer om. Scrum och 
MCV och Canvan, inte nödvändigtvis om djup kodning, då det inte är 
mitt kompetensområde, utan snarare metoderna att skapa det. Hur 
man får ett team att utveckla på bästa sättet. Både vad gäller 
övergripande design av lösningar så man kan vara med i 
diskussionerna, men även metoden för att kunna stötta dem. Det ser 
jag som den tekniska projektledarens uppgift, att stötta dem som 
faktiskt producerar produkten. 

27. Erik: Då går vi in på den näst sista kategorin som heter teknik. Då lyder 
första frågan, vilken teknisk kompetens anser du relevant för en 
teknisk projektledare? När vi menar teknisk så menar vi då 
programmerare, testare och drift/support. 

28. B1: Det beror nog på lite vilken typ av projekt det är. Men om vi säger 
den typen av projekt som vi bedriver, rena utvecklingsprojekt på .net 
plattformen då skulle jag säga att man behöver teknisk kompetens 
på alla de områdena, till olika djup. 

Testning, där är det mer en fråga om metod tror jag, än test 
exekvering, och test teorier. Det ligger lite utanför utvecklarna, 
medans test driven utveckling är absolut en kompetens man behöver 
kunna. Programmeringa, absolut man måste kunna utveckla och ha 
en bra. Nu får jag tänka efter lite. Man behöver inte alls kunna 
utveckla bra, men som jag sa tidigare så måste man ha förståelse för 
metoden man använder. Alltså metoderna som teamet utvecklar 
måste du som teknisk projektledare förstå. För annars blir du en 
administrativ person som räknar på timmar och gör grafer va. Och 
det är inte vad en teknisk projektledare i min värld skall syssla med. 
Det finns en administrativ projektledare som sitter och göra sådant. 
Men det var som jag sa till dig tidigare, TDD, MVC två typiska saker 
som du skall behärska och förstå på ett konceptuellt plan, men 
sedan tycker jag att man bör ha erfarenhet av programmering. Man 
måste förstå vad det innebär. 


29. Erik: Då kommer vi ställa en fråga som direkt leder till en följdfråga i form 
av ja eller nej. Då lyder frågan så här: 


Anser du att en teknisk projektledare bör ha tidigare erfarenheter av 
följande roller? 
Då börjar vi med programmerare 


30. B1: Absolut, ja är svaret på den frågan. 
31. Erik: Ser du några fördelar med att man kan programmera? 
32. B1: Ja alltså man har förståelsen och ansvaret för att driva fram ett 
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projekt, en projektledare ska driva ett projekt från ax till limpa. För att 
kunna driva det framåt så måste du förstå vad du är satt att göra och 
om i ditt team oberoende om det är två utvecklare eller 25 utvecklare 


så är det samma sak då har du erfarenhet av det och då pratar du 


samma språk som dem, du förstår metod, du förstår deras problem 
och kan agera på det. Det är också några av dina ansvarsuppgifter 


som teknisk projektledare 


33. Erik: Ser du några nackdelar med att du är programmerare i grunden? 
34. B1: Jaaa (Kort fundering) Det största problemet om du själv är 


programmerare och framförallt om du tycker det är kul så tenderar du 
att bli mer en utvecklare än en teknisk projektledare. Du engagerar 


dig i projektet och när projektet stöter på problem med tid och 


leverans och någonting sådant så är risken ganska stor att du själv 


sätter dig ner och programmerar då. Det är inte huvudsyftet då för 


dig som teknisk projektledare. 
35. Erik: Då tar vi nästa påstående och det är testare 


36. B1: (Längre paus) Det är svårt att svara på, det beror helt på hur man 


jobbar. I mitt fall så skulle jag säga nej, för mig är det inte jätteviktigt 
att dem som är tekniska projektledare har varit testare. Det beror på 


att utvecklarna som utvecklar inom vår organisation jobbar enligt 


Test-driven development, dem har det perspektivet och sen testare 


har en annan typ av kompetens. Där ligger ju då frågan om den 
tekniska projektledaren är ansvariga för testningen eller är det 


projektledaren som är ansvarig för testningen? Jag skulle säga att 
det är en gränsningsfråga, är man ansvarig för testning så är det bra 
att ha jobbat som testare men jag skulle säga att det är viktigare med 


programmerare än med testare. 
ST. SErik; Nästa påstående är Drift och support 


38. B1: (Längre paus) det är bra för det underlättar nästa steg i processen. 
En fantastiskt skriven produkt som inte kommer ut i drift och fungerar 


i drift är ingen fantastiskt skriven produkt hur estetiskt tilltalande 
koden än är. Men jag ser det inte heller riktigt som ett krav för där 


handlar det oftast om i dagens läge i alla fall som man jobbar så är 
det allt som oftast att ett utvecklingsprojekt och en driftsorganisation 
ganska separerat så det sker en formell överlämning mellan dessa. 
Då är det någon annan som ställer kraven på dig du kan få kraven 


utifrån du behöver inte uppfinna dem själv därmed så behöver du 


inte erfarenheten heller, men det är bra. Desto bredare kunskap som 


teknisk projektledare du har desto bredare förståelse har du. Jag 
skulle säga att kombinationen av några av dessa påståenden är 
viktigare än dem var för sig. Har du bara varit programmerare och 
teknisk projektledare sp kommer ditt fokus bara ligga på 
programmering. Hr du bara varit testare så kommer inte 


programmeringen inte vara så viktig men testerna är väldigt viktiga. 


För allt är lika viktigt i slutändan. 


39. Erik: Nästa påstående är Eftermarknad, har detta varit viktigt för dig? 


40. B1: (Kortare paus) Nej...det beror nog på att drift och support är vad jag 


ser som eftermarknad eftersom de bolagen jag arbetat i inte är 
kommersiella IT-bolag som säljer produkter så eftermarknaden är 


extremt nära själva internorganisationen. 


41. Erik: Då går vi vidare till sista frågan i teknikkategorin och den lyder så här 


Hur förhåller sig kommunikationen mellan er som teknisk 


projektledare mot beställare samt utvecklare? 


Med beställare menar vi personer som beställt systemet och 


finansierar projektet medans utvecklare är de som arbetar under er. 


Med kommunikation menar vi hur skiljer sig sättet ni pratar med 


dessa olika roller? 
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42. 


43. 


44. 
45. 


46. 


47. 


B1: 


Erik: 


B1: 


Erik: 


B1: 


Erik: 


Mindre idag än vad det tidigare har gjort tror jag. Det beror på att 
man börjar arbeta enligt metoder som också inkluderar beställaren. 
Beställaren kallar vi kanske idag för produktägaren inom Scrum, den 
är en del av en process. Tidigare arbetade man enligt 
vattenfallsmodellen, då pratar man två helt olika språk. Då pratar 
man kravställning här borta och teknik när kraven var klara sen var 
det den här svarta lådan som du stoppade in kraven i så fick du sen 
se vad du fick ut ur andra änden efter sex månader. Idag har den 
tekniska projektledaren och utvecklingsteamet mycket högre krav på 
sig att kunna prata affärsspråk än vad de hade tidigare. Förut var 
man mycket längre ifrån affärerna nu är man mycket tätare. För den 
som har beställt applikationen och har ett affärsspråk sitter allt som 
oftast i samma rum som dig och gör en planering av en backlog som 
är skriven på affärsspråk inte på IT-språk. Det är en jättestor fördel 
som jag ser det i hur man arbetar. Systemvetenskap har ju tidigare 
beskrivits som översättare mellan affären och tekniken men det 
handlar inte om det längre, man översätter inte man pratar redan 
samma språk. Det handlar om att facilitera processen inte att prata 
olika språk utan att det man pratar om blir gjort på ett bra sätt. Sen 
så är det här jätteskilt eftersom vissa jobbar med Scrum då är 
kommunikationen ganska likartad och det krävs ganska mycket 
utbildning av affärspersonerna också. Dem måste förändra sitt sätt 
att tänka och sitt sätt att kommunicera och det måste utvecklarna 
också. Sen finns det dem som fortfarande jobbar efter 
vattenfallsmodellen och som har väldigt täta skott mellan affären och 
dem som producerar produkten och då är det väldigt relevant att ha 
den här översättningsförmågan så att säga. 

Då är nästa kategori av frågor kompetens och då lyder första frågan 
så här: 


Har ni under er karriär arbetat som utvecklare? 


Ja, även fast det är en skymf att säga ja till det motsatt till dem jag 
ser utvecklar idag, men ja jag har jobbat med utveckling. 

Anser ni att det är viktigt att ha en yrkesmässig kompetens inom 
utveckling för att lyckas i rollen som teknisk projektledare? 

Under förutsättning att det är utvecklingsprojekt du är projektledare 
för. Det är inte mer än 20-30 260 inom industriell IT som handlar om 
utveckling. Det är mycket mer som handlar om implementation eller 
konfigurering eller Software-as-a-Service. Då är inte utveckling 
relevant för det finns inte inom väggarna av ditt företag, det är 
kravställning du ska vara duktig på och uppföljning och mätning. Men 
är du teknisk projektledare för ett utvecklingsprojekt och det är din 
ambition så absolut. 

Den följdfråga vi hade har vi nu redan fått svar på så vi hoppar vidare 
till nästa fråga. 

Nu kommer vi till en rangordningsfråga och den lyder så här: 

Vilka av följande tekniska kompetenser anser ni vara mest 
betydelsefullt för att kunna bedriva ett tekniskt projekt. Rangordna 
kompetenser nedan med det ni tycker är viktigast först. 


Jag tror du har kompetenserna framför dig 


Ja det har jag 

Sen skulle jag vilja be dig att ge en kort motivering också. 

(Längre tankepaus) Det beror lite på kontexten 

Ta det ifrån ditt eget perspektiv, så som ni själv upplever det 
Utvecklingsmetodik är nummer 1 och det beror på att du som teknisk 
projektledare är ansvarig för metoden. Det är du som ska se till att 
det finns en metod som fungerar. Sen är du inte ensam med att 
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jobba med metoden men du måste förstå den. 
Mjukvaruarkitektur skulle jag sätta som nummer 2, 


53. Erik: Varför anser du att det är viktigt? 

54. B1: Ja hur ska man förklara det, arkitektur blir viktigare och viktigare. 
Mjukvaruarkitektur kan man se på samma sätt som man ser på 
utvecklingsmetodik, det är metoden för att producera produkten. Där 
måste du ha kommunikationen med utvecklare med 
systemarkitekter, integrationsarkitekter och business arkitekter, det 
finns väldigt mycket arkitektroller och man pratar väldigt mycket 
arkitektur nu och då är det väldigt viktigt att vara med i den 
diskussionen och facilitera den. Genom utvecklingsmetodik och 
mjukvaruarkitektur så sätter du egentligen ramarna för projektet och 
utvecklingen i projektet och om ni ska lyckas eller inte. Gör man det 
rätt från början så har man väldigt goda förutsättningar att göra ett 
lyckat projekt. Ar det någon av dem som faller så är det stora risker 
att hela projektet faller. 

Som nummer tre hade jag sagt mjukvarukvalitet och förstå det och 
kanske värnas om att det inte försvinner. Det är också en del av 
metodiken, för utvecklare måste det vara en del av metodiken annars 
kommer man aldrig att testa, det måste byggas in i systemet. 
Utvecklare gillar inte att testa, det är därför det finns utvecklare och 
testare. 

Kunskaper i människa-data interaktion tror jag skulle få 4 då. Vi är så 
pass duktiga att utveckla och lösa affärsproblem idag och vi har så 
pass bra verktyg till det att lösa själva problemet är sällan själva 
frågan utan att se till att projektet är intuitivt, dynamiskt och 
användbart är en utmaning. Detta är egentligen vad din beställare 
ser, det spelar ingen roll om du har 40000 rader kod och du har ett 
problem som du har löst som aldrig lösts av någon annan i hela 
världen. Förstår inte användare som använder det så skapar det 
ändå inget värde. 

Djup programmeringskunskap skulle komma på sista plats för det är 
vad dina utvecklare ska ha. En utvecklare ska ha ramar i form av 
arkitektur och sen ska han vara frisläppt inom dem ramarna för att 
göra på bästa sätt, testa nya saker, hitta ett sätt att effektivt arbeta i 
teamet. Har du för djupa kunskaper inom programmering så är risken 
att endera att du engagerar dig i utveckling, det är inte ditt uppdrag. 
Eller nummer två att du försöker påverka utvecklingen, inskränker 
utvecklarnas frihet genom att försöka berätta i detalj vad dem ska 
göra och det är kontraproduktivt så det skriver om det. Så därför 
hamnar den som nummer 5 då. Du ska inte älska programmering, då 
ska du inte bli en teknisk projektledare. 


55. Erik: Finns det någon kompetens som kan vidareutvecklas i strävan att bli 
en bättre projektledare? Då kan du se till dig själv, eller generellt sätt. 
56. B1: Overgripande projektplanering då. Som sträcker sig utanför 


mjukvaruutvecklingen. Som teknisk projektledare så har du ett fokus, 
du är förmodligen ansvarig för utvecklingen av ett projekt. Din del 
kanske sträcker sig över 6 månader, och helhetsprojektet kanske 
sträcker sig över två år. Ju mer förståelse du har för vad som pågår 
genom hela kedjan, och ju mer input du kan ge till dem runt omkring 
dig, beställare, projektledare, styrande kommittee, även om det inte 
är du som har de direkta interfacen, ju mer du förstår den processen 
och de språken som används där desto bättre tror jag du kan jobba. 
Mjukvaruutvecklingsprojekt påverkas oftast inte negativt av vad som 
sker inom ett utvecklingsteam. Utan det påverkas av vad som sker 
runtomkring, request for changes en bra sådan process eller en bra 
sådan process men den går för fort. Så förståelsen för omvärlden 
och hur den fungerar är väldigt viktig, för du är ju någon sorts 
gatekeept, precis som att du skall driva ett projekt framåt för att få ett 
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57. Erik: 


team att jobba vettigt så måste du också vara den som hindrar andra 
människor från att komma in och störa teamet. Du skall inte 
avskärma dem från omvärlden men du skall se till att styra vilka 
intryck dem skall se och när. Det tror jag kan vara viktigt. 

Då är vi nöjda där. Tack så mycket! 
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Tabell B2.3 Intervju med C1 (2011-04-19) 


ig 
2. 


Fd > Ean 


17. 


18. 


19. 


21. 


23. 


Erik: 
C1: 


Erik: 
C1: 


Erik: 
C1: 


Erik: 
C1: 


Erik: 


Gi: 
Erik: 
C1: 
Erik: 


C1: 
Erik: 


C1: 


Erik: 


C1: 


Erik: 


Vad är din titel idag? 

Acting Sektionschef, vanligt sett är jag subdistributionsarkitekt det betyder att 
jag har det slutgiltiga ansvaret för kvalitetsansvaret för applikationsmjukvaran. 
Se till att man uppfyller alla dem krav som finns på delar av program och 
applikation. 

Vilka tekniskt inriktade arbetsuppgifter har du och med tekniskt menar vi 
programmering, test och drift/ support. 

Jag har jobbat väldigt mycket i projekt innan. 

Idag så utför du inga egentliga tekniska uppgifter, till exempel programmering? 
Som min permanenta roll där är jag, huvudsakligen granskande. Men samtidigt 
så är det jag som kan alla verktyg. Så jag utför programmering också. Vissa 
grejer fixar jag själv. 

Inkluderar det något med test och så vidare? 

Med test så har vi ändrat oss lite, vi har lyft upp en annan roll, parallellt med 
den här arkitektrollen som jag har och det är ens motsvarande som tar ett 
ansvar för testsidan av det. Men kanske lite mer mot rutinerna kring 
regressionstesta och sådana saker. Som mitt jobb innebär också att se till att vi 
har väldigt bra testteckning och ständigt sträva efter när det gäller nyutveckling 
så försöker vi se till att få ett lyft när det gäller testbiten så att det inte släpar 
efter utan snarare att det bara blir bättre och bättre. 

Då går vi vidare till nästa fråga som handlar lite om dina tidigare erfarenheter 
inom IT-branschen. 

Kan ni beskriva kortfattat vad ni har för tidigare jobberfarenheter inom IT- 
branschen. Hur har det lett fram till den positionen ni har idag? 


Ska jag börja 1985? 

Hehe...Om du kan så kortfattat, jag förstår att det är en resa 

Ja det är en resa, (längre paus) Man kan säga att jag började som utvecklare. 
Jobbat bitvis med projektledning och teamledning också. Sen har det blivit 
arkitekthållet de senaste 8-9 åren 

Ja det var väldigt bra kortfattat...Av de jobben som ni haft vilket har haft mest 
betydelse för den projektledarroll ni har idag 

Det är inte så lätt att peka ut...(längre paus) 

Tror ni att det kan ha varit utvecklingskunskapen som lade grunden för 
kunskaperna eller kan det vara något annat? 

Det är ju bra, man ska veta vad det innebär, på det sättet så är det jätteviktigt 
att man liksom har fått en naj i att man har jobbat med utveckling och vet vad 
det innebär, vad som är jobbigt och vad som är mindre jobbigt och vad som är 
görbart. (Längre paus) 

Generellt så tror jag att det är jätteviktigt för en projektledare. 


Så då kommer vi in på projektledningsfrågorna. Då lyder frågan så här 
Vilka projektledningserfarenheter har du haft om du haft några innan du fick 
jobbet som du har idag som arkitekt eller tekniskt projektledare som vi kallar 
det 


Det var länge sen jag jobbade som projektledare så jag tror inte att det var det 
som lett till rollen jag har idag som arkitekt. 

Då ska vi se. Då kommer vi visa en bild som jag har glömt att ta upp innan. Det 
är en bild av projektets livscykel och då kommer vi fråga vart i den här 
livscykeln, eller i vilken fas av den här livscykeln som ni anser att era tekniska 
kunskaper är av störst vikt. 

Jag kan flytta mig. (En paus innan Erik får upp bilden på livscykeln) Nu ska vi 
se här. 

Som ni kan se finns det tre huvud faser då och sen är det dem här del faserna. 
Och frågan är? 

Frågan lyder: Under vilken fas under projektets livscykel att de tekniska 
kunskaperna är av störts vikt. Ar det under en huvud fas eller mer specifikt 
under någon del fas? 
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24. C1: Eeeeh, det är ju under förstudiebiten. (lång paus) Sen är det...vissa av dessa 
del faser ser jag inte som så stora skillnader. Analys, utformning och 
konstruktion och test samt i de tidigare faserna som det ligger. 


25. Erik: Då kommer nästa fråga, har ni genomgått någon projektledningsutbildning 
under ert yrkesverksamma liv? 

26. C1: Ja det har jag gjort 

27. Erik: Vilka kunskapsområden syftade dem att förstärka er i? 

28. C1: Det var nog rätt mycket med olika verktyg för att projektplanera och sådana 
bitar. 

29. Erik: Exempelvis Ganttschema och liknande? 

30. C1: Ja typ, projekt..eeeeh men även jag tror det var rätt mycket av de mjuka 


grejorna också. Jobba med teambuildning. Till exempel vad det är som får 
team att fungera och så vidare och mer av de mjuka bitarna som är otroligt 


viktiga. 

31. Erik: Känner ni att ni haft användning av den här utbildningen när ni arbetat som 
projektledare. 

32. C1: Ja absolut 

33. Erik: Nu ska vi se, vilken utbildning anser ni har varit viktigast av de ni har 
genomgått och använt? 

34. C1: (Lång paus) Jag tror nog på något sätt att man inser vikten av det lite mjukare 


bitarna, vad är det som motiverar folk att göra saker. Alla liksom när det finns 
verktyg att det finns olika sätt. Får man inte människorna med sig och inte kan 
motivera göra saker så funkar det inte. Utan det är egentligen, det tror jag är 
som det jag haft mest användning av. 

35. Erik: Då kommer sista frågan inom projektledningskategorin. 
Finns det några projektledaregenskaper som ni känner att ni saknar för att bli 
en mer kompetent projektledare och speciellt om man ser det ur en teknisk 
synvinkel. För att kunna leda tekniska projekt 


36. C1: Just det teknisk. (Längre paus) Svårt. 

37. Erik: hade du känt att det generellt hade behövts bättre 
programmeringsförkunskaper 

38. C1: För mig då? 

39. Erik: Ja om du ser från din egen synvinkel men också om du haft kontakt med andra 
tekniska projektledare också 

40. C1: Men alltså, programmerar en teknisk projektledare? 

41. Erik: Om man säger att han ska leda programmerare 

42. C1: Nej, absolut inte, jag tycker inte att projektledaren ska behöva . Nu säger jag 


emot mig själv lite grann. En projektledare, den rollen kräver nog att man, man 
får nog inte sitta och programmera själv och så. Man ska förstå vad det innebär 
för att man ska kunna bedöma andra människors uppskattningar och så vidare 
och hur dem liksom säger att det här kan in inte göra, då ska man förstå. Jag 
tror inte jag att man ska gå och lura sig att det är så lätt som helst heller, man 
ska ha koll och känsla för det men man behöver inte vara speciellt vass på det. 
Utan jag hävdar nog att återigen att det är mycket mer dem här, dels är det de 
här mjuka sakerna mot teamet men sen som projektledarens, många gånger 
så är den stora utmaningen att argumentera för sin sak, att man är väldigt 
duktig att framföra sin åsikt och kunna kämpa för sina projekt så att säga. Så 
det är mycket att kunna kommunicera både uppåt och neråt. 

43. Erik: Då lämnar vi faktiskt projektledningsfrågorna och går in på lite teknikfrågor. 
Då undrar jag först så här. 
Vilken teknisk kompetens anser du relevant för en teknisk projektledare, vad vi 
menar med teknisk kompetens är då programmering, test, drift och server. Det 
är inom dem områdena, vilken kompetens anser du relevant. 


44. C1: I vårt fall är det dem två första, utveckling och programmering och test 
45. Erik: Finns det någon teknisk kompetens som du kan lägga till utöver dem? 
46. C1: Teknisk? 

47. Erik: Ja 
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C1: 


2 


C1: 


Ei 


Alltså det är en sak som jag inte vet om det är teknisk, men man ska ju också 
förstå vad det är man gör för någonting och vad man använder det till och vem 
har för glädje av det här, varför gör man det här? 

Annars ligger tyngden på programmering och testning 

Ja men det är för att den är sånt vi inte håller på med. 

Men det finns inget business Intelligence för att kunna leda projekt 

Nej 

Okej vad bra. 

Vi hoppar till nästa fråga. Och det blir en fråga där jag presenterar några 
påståenden. Och så kommer du behöva svara ja och nej följt av en kort 
motivering. Anser du att en teknisk projektledare behöver ha tidigare erfarenhet 
av följande roller: 

Roll 1. Programmerare, ja eller nej? 


Sa du behöver ha? 

Ja, om de bör ha en tidigare erfarenhet? 

Ja, ok. I vårt fall, Nej, får jag nog säga. Det är kanske bra, men det finns andra 
egenskaper som är viktiga. Det är inte det viktigaste. 

Då går vi över till nästa, och då är det testare, är det viktigt att ha som 
förkunskap om man skall bli en teknisk projektledare? 

Samma sak här, det är ju inte det viktigaste. 

Vi går vidare till nästa fråga, drift och support, är det viktigt? 

Jag vet inte om det är så tillämpbart i vårt fall. 

Sista frågan är då eftermarknad. När produkten är levererad och anses vara 
färdig. Kanske ses lite som support då också, man skall ha en eftermarknad 
och jobba med det. 

Nej 

Bra, tack så mycket. Nästa fråga är kring kommunikation, och frågan lyder: 
Nu hittar jag inte frågan, den har visst kommit bort. 

Jo, där har vi den. 

Det handlar om olika roller, och då lyder frågan, hur förhåller sig 
kommunikationen mellan er som teknisk projektledare mot en beställare och 
emot en utvecklare, och en beställare är i det här fallet kunderna, och 
utvecklarna de som tar fram systemet. Hur skiljer sig kommunikationen 
sinsemellan där? 


Hur de skiljer sig? 

Ja, och finns det någon skillnad? 

Just nu så kör vi, eller försöker skapa team där vi har produktägare blir en del 
av, eller väldigt delaktig i teamets arbete, projektledaren är ju den som hjälper 
till att planera upp grejer. Skillnaden i kommunikationen, jag tror 
kommunikationen med utvecklarna är lite tätare, daglig basis, ständig 
kommunikation. Men mot beställare så är det mindre frekvent, men ändå tight. 
Men har det kommit att ändras på senare tiden eller har det med 
utvecklingsmetodiken att göra? 

Ja det är ju det här med att försöka få det med agilt arbete. Vi har ju kört 
mycket vattenfall. Det tenderar att bli mycket vattenfall och det är det vi 
försöker ta oss ifrån. Men annars vet jag inte om det är direkt skillnad, utan 
snarare hur mycket. 

Då kommer vi in på sista kategorin av frågor, och det är kompetens. Då börjar 
vi med frågan: Har ni under er karriär arbetat som utvecklare / programmerare? 
Ja. 

Anser ni att det är viktigt att ha en yrkesmässig kompetens inom utveckling för 
att lyckas i rollen som teknisk projektledare? 

Yrkesmässig? 

Ja att du har jobbat som programmerare för att lyckas axla en roll som teknisk 
projektledare. Anser du det viktigt 

Nej , det är viktigt med det är inte det viktigaste. 

Vad anser du då har mer betydelse? Du har varit inne och berört detta tidigare 
med mjuka värden, men finns det något som du ser är påtagligt viktigare än 
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programmering och tekniska kunskaper? 

Tror det är mycket om man skall lyckas så måste man kunna prata om sin sak, 
och vara duktig och känna folk, ha kontakter och kunna argumentera för sitt 
projekt. De är lite mjukare saker egentligen. Jag tror inte att det är att man 
kommer med massa tekniska argument, utan det har man som teknisk 
projektledare ofta, behöver man det så har man experter till det. Då tar man 
med sig en sådan expert om man behöver det. Utan det handlar om att man 
skall kunna röra sig inom en organisation och veta vad som förväntas av en, 
vad man vill göra, och puscha på rätt ställen för att få det här att glida igenom 
smärtfritt. Vi har många trånga passager som man skall gå igenom med sitt 
projekt, och har man då bra egenskaper som projektledare så är det lätt att 
slinka igenom snyggt och prydligt. Det gäller att veta vad folk vill ha i förhand 
och vara förberedd för det. Men att komma som argument som en klassisk 
programmerar gör så tror jag inte det är var som behövs utan det finns alltid 
folk som kan sådant. 

Bra utveckling på frågan. Då kommer vi till nästa fråga som är en 
rangordningsfråga. Du kommer se de olika alternativen på min dator, men jag 
ställer frågan först: 

Vilka av följande kompetenser anser ni vara de mest betydelsefulla för att 
kunna bedriva ett teknisk projekt. Då kan du börja säga vilken du tycker är 
viktigast följt av en kort motivering. 


Ja det är goda kunskaper inom utvecklingsmetodiken som är nr. 1. Det där de 
mjuka bitarna kommer in. Den som kommer på sista plats kan jag säga direkt 
är att ha djup programmeringskunskap. Inom vårt område så tror jag nog, 
mjukvarukvalitet vill jag har före kunskaper om människor och dator interaktion. 
Så mjukvarukvalitet blir tvåa då, och människor data interaktion tre. 

Ja, och så arkitektur näst sist. 

Den är inte lika viktig pga.? 

Samma sak där, så tror jag att ofta har man någon som har den kunskapen till 
sin hjälp. Alltså projektledaren som jag tänker mig, håller inte alls på med, eller 
inte kan detaljerna. Utan mer förstå vad man vill åstadkomma, och navigera sitt 
team genom en organisation. Ja vet inte riktigt om det är det ni är ute efter? 

Jo då, du har en intressant punkt där, som jag inte tänkt på. 

Nu är vi faktiskt redan på sista frågan. Försök svara på denna så gott du kan 
då. 

Finns det någon kompetens som ni skulle kunna förbättra för att kunna bli en 
teknisk projektledare? Då får du tänka dig i rollen du har nu, eller när du 
ansvarar för tekniska projekt. 


Det blir en sånhär mjukis grej igen, jag får säga argumentation. 

Är det något annat som du kan se generellt skulle kunna behövas förbättras, 
om du ser på andra projekt som genomförts med en teknisk projektledare. 
Någon annan kompetens du skulle vilja sett fått mera utrymme? Kanske är 
samma sak igen. 

Inte rent traditionell kompetens. En annan sak som man traditionell 
projektledning som vi håller på med är tänka på säljande delen. Vi gör mycket 
projekt och lägger ner mycket tid, kärlek och hat och allt vad det är för att få till 
det, och hoppas att någon vill ha det, men ofta i en såhär stor organisation så 
märker man ofta av att det finns verksamhet som man inte känner till , eller 
berättat om. Som teknisk projektledare tycker jag det är viktigt att blir bättre på 
att synliggöra det man gör, och visa att på något sätt. Vi har best application of 
the month, att man puschar att få teamet ditt. 

Tack så mycket för alla svar. 
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Tabell B2.4 Intervju med D1 (2011-04-20) 
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Då börjar vi intervjun helt enkelt med de första bakgrundsfrågorna och den 
första lyder då helt enkelt 
Vad är din titel idag? 


Jag går under senior utvecklare/Teknisk projektledare 

Okej 

Där den tekniska projektledaren är mer ett mål än en titel 

okej 

Då lyder nästa fråga: 

Vilka tekniskt inriktade arbetsuppgifter har du haft, då med tekniskt så menar vi 
programmering, test och drift samt server. 

Huvudsakligen utveckling men också i och med att jag jobbat i lite mindre 
företag så blir det ju att man kör test och även drift och sånt samtidigt. Det är 
inte drift för stora företag i den bemärkelsen utan det är att se till att servrar och 
databaser och backuper funkar. Allt sånt liksom, den typen utav drift. 

ja absolut, då ska vi se här. 

Kan ni beskriva kortfattat vad ni har för tidigare jobberfarenheter inom IT- 
branschen? 


Jag började som utvecklare i Qlikview framförallt, VB6 och sen har jag gått in 
på .net och passerat java också på vägen. Jag hade också en ansvarsroll där 
jag var ansvarig över två andra personer och levererar saker vi utvecklade, så 
jag ledde själva arbetet. Sen har jag jobbat som konsult i ett antal år då i olika 
form av utvecklingsuppdrag i olika miljöer. Det har varit allt från kodning till 
konfiguration helt enkelt. Så det är ganska brett spann. 

Hur många år har du varit ute? 

Jag börjar väl, jag är inne på mitt 10:e år i år. 

Okej 

Då blir det en liten följdfråga på den också: 

Av de jobb som ni haft, vilken har haft mest betydelse för den rollen som ni har 
idag? 


Alltså, utvecklingen är ju själva stommen i det jag håller på med och så är det 
fortfarande. Det är liksom en ryggsäck som man aldrig kan slänga av sig. Men 
även dem här ledarskapsbitarna som man tar med sig, men det är ju inte så 
mycket teknik i det. 

Men det leder väl in lite i nästa punkt då som handlar om projektledning, då är 
första frågan i den kategorin: 

Vilka projektledningserfarenheter hade du om några innan du fick jobbet som 
teknisk projektledare? 


Nu har jag inte formellt jobbat som teknisk projektledare, det krävs ju en viss 
definition av vad en teknisk projektledare är men i dagsläget så sitter jag då 
inte i någon sorts projektledarroll, utan det är ju i så fall den enda leverantören 
emot en organisation som inte har något tekniskt kunnande och då i princip 
sköter allting själv, där man beställer databas till kodning och dokumentation 
och alltihopa, leverera allt i en och samma person liksom. 

jaja. Nu ska vi se här. Nu ska jag visa dig en bild här också på projektets 
livscykel, då ska vi se, ligger den under material gör den? 

Sådär har vi definierat den: 

Då är den frågan till den där bilden: 

Under vilken fas av projektets livscykel som du ser där anser ni att era tekniska 
kunskaper är av störst vikt? 


Utan störst vikt? 

Ja 

Alltså i dem grova (intervjuobjektet syftar till huvuddelarna av projektets 
livscykel) 

Eeh, du kan nog ta båda, det spelar ingen roll (Syftar till både huvuddelarna 
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och underdelarna av projektets livscykel). Det är nog många som går in lite i 
varann där också. 

Som jag ser det så är det tekniska kunnandet viktigt egentligen ur 
projektledarsynvinkel i början, alltså inte när man kommer på en idé, men 
däremot när man gör en förstudie av själva projektet och när man startar upp 
det. Sen när man kommer in i själva arbetet så flyter ju oftast på ganska bra. 
Så det är som en puckel liksom den tekniska, det är ju mer viktigt, inte i den 
absoluta uppstarten utan när man kommit in i förstudien och förarbetet. Sen i 
själva produktionssättningen så behöver man kanske inte så mycket teknisk 
kunskap för att genomföra det, men det är ju själva produktionssättningen, 
definitionen utav det har man ju redan gjort liksom när man definierar projektet 
men själva fysiska produktionssättningen är ju oftast ganska enkelt och 
behöver oftast ingen ledning om man har definierat projektet väl, hur man ska 
göra liksom så ju längre man kommer i processen desto mindre tekniskt 
kunnande för projektet i sig själv har ju fått en bredare teknisk kunskap hur man 
nu ska säga. 

Ja, tack så mycket. Eeeh yes: 

Har ni genomgått någon projektledarutbildning under ert yrkesverksamma liv? 


Nej 

Nej 

Då ska vi se 

Finns det några projektledaregenskaper som ni saknar för att bli en mer 
kompetent tekniskt projektledare 


eeeh... där borde man ju svara nej..hehehe man kan ju alltid blir bättre på att 
planera och strukturera sitt arbete och jobba mer strukturerat. Det kan ju oftast 
bli ganska hoppigt eftersom det dyker upp massa saker under tidens gång så 
får man ta 4 snedsteg så får man börja om. 

ja det avslutar projektledningskapitlet och glider in osökt in på teknik, då är vi 
tillbaka till: 

Vilken teknisk kompetens anser du relevant till en teknisk projektledare, då är 
det samma definition av teknisk alltså programmering, test, drift och support. 


Alltså det är ju bra om man har erfarenhet utav alltihopa egentligen men om 
man ser det ur ett utvecklingsprojekt, om det är det man ska så är det kanske 
viktigare att ha en utvecklarbakgrund, ofta när man har en utvecklarbakgrund 
så har man lite av test och lite av drift i sig då. Man kan ju jobba som testare 
utan att ha skrivit en enda rad kod egentligen men det är svårt att jobba som 
utvecklare utan att ha gjort ett test. Jag har fått in mer kompetens av att jobba 
som utvecklare än att jobba som testare. Eller en vanlig It-tekniker, det är ju 
inte ens säkert att dem ens kan skriva en rad kod heller. Men när man är 
utvecklare så har man oftast installerat några servrar och så där i testmiljö, 
man har ju ändå en viss kunskap om det 

Om man ser i det breda spektrumet så är allt bra men just programmerare och 
utvecklare är nog ändå de som.. 

Ja om vi pratar systemutvecklingsprojekt, för det kan ju finnas andra projekt där 
man kan behöva en teknisk projektledare i form utav, jag vet inte, utrullning av 
en applikation eller något sånt där. Det jag tänkte komma till är ju att det är 
utveckling som tar upp mest resurser i ett projekt, och om du har en 
utvecklarbakgrund i ett utvecklingsprojekt så har du kanske lättare att se varför 
saker och ting tar tid eller hur lång tid saker borde ta eller den typen utav 
frågeställningar 

Nu kommer vi ha ett antal frågor, som är vissa påståenden. Där är det svar 
iform av ja och nej, och sedan kommer en följdfråga på varför då. Så första 
frågan, anser du att en teknisk projektledare bör ha tidigare erfarenheter av 
följande roller: 

-Programmerare 


Ja , det tycker jag. 
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Okej, vad finns där då för fördelar och nackdelar med att ha den bakgrunden? 
Jag tycker att, just att i att om vi igen pratar om systemutveckling, att man har 
en förståelse för att vissa saker tar långt tid, att vissa saker inte går att göra. 

Ja precis, lite som vi var inne på innan. 

Och, så jag måste säga att det är nog. 

Finns det några nackdelar med att komma från en programmerar bakgrund? 
Ja, man kan bli låst i sitt tänkande, eller att man går in, jaja, det där är ju inte så 
svårt det gjorde ju jag när jag jobbade som utvecklare, att man har den 
attityden. Att man inte låter utvecklare vara utvecklare, och att man går in och 
styr arbetet för mycket, för man själv haft en utvecklarbakgrund. 

Ja, bra! Då blir nästa påstående, om man har erfarenhet som testare? Fördel, 
nackdel? 

Ja, det är en fördel att man förstår fördelen med test, och hur man kan testa, 
och test metodiker som kan passa på olika delar beroende på vad man skall 
testa. Men det är ju också beroende på hur projektet ser ut och i vilken miljö 
man jobbar i eller reglerad verksamhet där det krävs mycket testning. Då är det 
en viktigare bakgrund än att vara en utvecklare. 

Ok, och någon nackdel kring att ha varit testare? 

Nej, det är samma där också, att man inte låter testarna välja testverktyg, man 
går in och petar i testarnas val av test metodik. 

Sedan kommer nästa fråga, som är drift och support, om det är en bra 
erfarenhet. 

Ja, det är det väl! För mig är inte det de mest komplexa delen av ett projekt. 
Inte i alla organisationer, men i vissa är det. Det känns som det är något man 
hänger på som är ganska standardiserat 

mm, ok. Sedan har vi definierat den sista frågan som eftermarknad, den går lite 
ihop med drift och support men just när man levererat en produkt och man 
anser den vara färdig, den efterföljande tiden. Om man varit med om den 
processen. 

Ja visst, det kan vara bra, men jag ser det inte heller som någon stor grej. Då 
har oftast projekt avslutat så det är oftast de inom organisationen som tagit 
över det då. Så det är mer förberedelserna innan de, och det skall egentligen 
linje organisationen definierat vad de tycker, hur det skall se ut efteråt. Jag kan 
inte se att det är någon jätte grej för en tekniskt projektledare då det redan skall 
vara färdig definierat som jag ser det. 

ok, japp. NU skall vi se. Då kommer nästa fråga. Hur förhåller sig 
kommunikationen mellan dig som teknisk projektledare dels när du pratar dels 
med utvecklarna eller beställare är det olika sorters kommunikationen? 

Hur förhåller sig kommunikationen mellan er som teknisk projektledare mot 
beställare samt utvecklare? 


Ja, det viktiga är att man agerar något sorts filter. Man måste prata med 
utvecklarna på utvecklarnas språk och beställarna på beställarnas språk. Det 
är väl det som är själva grejen. Att försöka lyfta kommunikationen med 
beställarna, att försöka förstå vad de egentligen säger, eller inte säger. Annars 
blir det lätt att man bara sitter och översätter alla deras önskningar rätt ner till 
utvecklarna, så är det inte vad de egentligen vill ha. Utan man måste på något 
sätt tolka deras krav behov på något sätt och kanske filtrera och prioritera olika 
saker. 

Gött! Då är vi inne på sista kategorin som handlar om kompetens, och då lyder 
frågan: 

Har ni under er karriär arbetat som utvecklare? 


Ja 

Anser ni att det är viktigt att ha en yrkesmässig kompetens inom utveckling för 
att lyckas i rollen som en teknisk projektledare? 

Jag tror att det är viktigt men att man kan lyckas ändå. Jag ser inte det som ett 
jätte krav men att man någonsin har skrivit kod tror jag är viktigt. Att man har 
förståelse för vad det innebär. 

Ar det då något annat som ni kan se är viktigt än att just ha en yrkesmässig 
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erfarenhet av utveckling? 
Jag tror överhuvudtaget som projektledare så krävs det väldigt mycket 
erfarenhet. Det är svårt att få det om man inte är med i någon typ utav projekt 
och då måste man ta någon typ utav roll, och de allra flesta rollerna som folk 
har är utvecklare, det är den största kategorin. Det blir oftast att man har den 
bakgrunden. Jag tycker att det krävs, man kan inte komma direkt ifrån skolan 
och tro att man skall bli en bra projektledare, man kan tycka det, men jag tror 
inte det funkar, det krävs ändå några års erfarenhet. Det är bra att låta någon 
annan göra misstagen så man kan stå vid sidan och titta på än att man måste 
göra alla misstagen själv. 
Ja, precis. Då kommer vi till en ranking fråga här. Då är det fem olika 
påståenden här inom kompetenser. Vilken av följande fem kompetenser anser 
ni vara viktiga för att kunna bedriva ett tekniskt projekt, rangordna den 
viktigaste först: 
Jag skulle säga 

1. Arkitektur, är detta de kunskaper den tekniska projektledaren skall ha? 


Ja, precis. 

Ok, då tycker jag, 1. Arkitektur, 2. Mjukvarukvalitet, sedan 3. Djup 
programmeringskunskap, sedan 4. Utvecklingsmetodik och sedan 5. Människo 
data interaktion. 

Tackar! Då är vi inne på den sista frågan för idag. Finns det någon kompetens 
ni anser kan utvecklas vidare i strävan att bli än ännu bättre teknisk 
projektledare? 

Ja, svår fråga. Det är alltid det här med att bredda sin kunskapsbas, och inte gå 
djupare för det har man ofta ingenting för, men just att försöka bli bredare. Att 
försöka få kompetenser från hela spannet som man egentligen jobbar med, ur 
ett tekniskt perspektiv då. Att kunna förstå varför man utför tester, om det är nu 
det man är lite sämre på. Att man försöker få in hela projektets tekniker, så 
man förstår innebörden av det. 

Jal, Då tackar vi så jättemycket. 
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